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Foreword 


The  Federal  Information  Processing  Standards  Publication  Series  of  the  National 
Institute  of  Standards  and  Technology  (NIST)  is  the  official  publication  relating  to 
standards  and  guidelines  adopted  and  promulgated  under  the  provisions  of  Section 
1 1 1  (d)  of  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended  by 
the  Computer  Security  Act  of  1987,  Public  Law  100-235.  These  mandates  have  given 
the  Secretary  of  Commerce  and  NIST  important  responsibilities  for  improving  the 
utilization  and  management  of  computer  and  related  telecommunications  systems  in 
the  Federal  Government.  The  NIST,  through  its  Computer  Systems  Laboratory, 
provides  leadership,  technical  guidance,  and  coordination  of  Government  efforts  in  the 
development  of  standards  and  guidelines  in  these  areas. 

Comments  concerning  Federal  Information  Processing  Standards  Publications  are 
welcomed  and  should  be  addressed  to  the  Director,  Computer  Systems  Laboratory, 
National  Institute  of  Standards  and  Technology,  Gaithersburg,  MD  20899. 


James  H.  Burrows,  Director 
Computer  Systems  Laboratory 


Abstract 


The  Integration  Definition  for  Function  Modeling  (IDEFO)  is  based  on  the  Air  Force 
Wright  Aeronautical  Laboratories  Integrated  Computer-Aided  Manufacturing  (ICAM) 
Architecture,  Part  II,  Volume  IV-Function  Modeling  Manual  (IDEFO),  June  1981. 

This  standard  describes  the  IDEFO  modeling  language  (semantics  and  syntax), 
and  associated  rules  and  techniques,  for  developing  structured  graphical  representa¬ 
tions  of  a  system  or  enterprise.  Use  of  this  standard  permits  the  construction  of  mod¬ 
els  comprising  system  functions  (activities,  actions,  processes,  operations),  functional 
relationships,  and  data  (information  or  objects)  that  support  systems  integration. 

Key  words:  activity  model;  business  process  improvement;  business  re-engineering; 
Federal  Information  Processing  Standard  (FIPS);  function  model;  graphical  language; 
IDEFO;  modeling  language. 
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1993  December  21 

Announcing  the  Standard  for 

INTEGRATION  DEFINITION  FOR  FUNCTION 
MODELING  (IDEFO) 


Federal  Information  Processing  Standards  Publications  (FIPS  PUBS)  are  issued  by  the  National  Institute  of  Standards  and 
Technology  (NIST)  after  approval  by  the  Secretary  of  Commerce  pursuant  to  Section  1 1 1  (d)  of  the  Federal  Property  and  Administra¬ 
tive  Sen/ices  Act  of  1949  as  amended  by  the  Computer  Security  Act  of  1987,  Public  Law  100-235. 


1.  Name  of  Standard.  Integration  Definition  for  Function  Modeling  (IDEFO). 

2.  Category  of  Standard.  Software  Standard,  Modeling  Techniques. 

3.  Explanation.  This  publication  announces  the  adoption  of  the  Integration  Definition  for  Function 
Modeling  (IDEFO)  as  a  Federal  Information  Processing  Standard  (FIPS).  This  standard  is  based  on  the  Air 
Force  Wright  Aeronautical  Laboratories  Integrated  Computer-Aided  Manufacturing  (ICAM)  Architecture, 
Part  II,  Volume  IV- Function  Modeling  Manual  (IDEFO),  June  1981. 

This  standard  describes  the  IDEFO  modeling  language  (semantics  and  syntax),  and  associated  rules 
and  techniques,  for  developing  structured  graphical  representations  of  a  system  or  enterprise.  Use  of  this 
standard  permits  the  construction  of  models  comprising  system  functions  (activities,  actions,  processes, 
operations),  functional  relationships,  and  data  (information  or  objects)  that  support  systems  integration. 

This  standard  is  the  reference  authority  for  use  by  system  or  enterprise  modelers  required  to  utilize 
the  IDEFO  modeling  technique,  by  implementors  in  developing  tools  for  implementing  this  technique,  and 
by  other  computer  professionals  in  understanding  the  precise  syntactic  and  semantic  rules  of  the  standard. 

4.  Approving  Authority.  Secretary  of  Commerce. 

5.  Maintenance  Agency.  Department  of  Commerce,  National  Institute  of  Standards  and  Technology, 
Computer  Systems  Laboratory. 

6.  Cross  Index. 

a.  ICAM  Architecture  Part  II,  Volume  IV- Function  Modeling  Manual  (IDEFO),  AFWAL-TR-8 1-4023, 
Materials  Laboratory,  Air  Force  Wright  Aeronautical  Laboratories,  Air  Force  Systems  Command,  Wright- 
Patterson  Air  Force  Base,  Ohio  45433,  June  1981. 

7.  Related  Documents. 

a.  Federal  Information  Resources  Management  Regulations  Subpart  201.20.303,  Standards,  and 
Subpart  201.39.1002,  Federal  Standards. 

b.  Integrated  Information  Support  System  (IISS),  Volume  V- Common  Data  Model  Subsystem, 
Part  4  -Information  Modeling  Manual-IDEFI  Extended,  December  1985. 

c.  ICAM  Architecture  Part  II,  Volume  V- Information  Modeling  Manual  (IDEF1),  AFWAL-TR-8 1-4023, 
Materials  Laboratory,  Air  Force  Wright  Aeronautical  Laboratories,  Air  Force  Systems  Command,  Wright- 
Patterson  Air  Force  Base,  Ohio  45433,  June  1981. 

d.  ICAM  Configuration  Management,  Volume  II  -  ICAM  Documentation  Standards  for  Systems  Devel¬ 
opment  Methodology  (SDM),  AFWAL-TR-82-4157,  Air  Force  Systems  Command,  Wright-Patterson  Air 
Force  Base,  Ohio  45433,  October  1983. 
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8.  Objectives.  The  primary  objectives  of  this  standard  are: 

a.  To  provide  a  means  for  completely  and  consistently  modeling  the  functions  (activities,  actions, 
processes,  operations)  required  by  a  system  or  enterprise,  and  the  functional  relationships  and 
data  (information  or  objects)  that  support  the  integration  of  those  functions; 

b.  To  provide  a  modeling  technique  which  is  independent  of  Computer-Aided  Software  Engineering 
(CASE)  methods  or  tools,  but  which  can  be  used  in  conjunction  with  those  methods  or  tools; 

c.  To  provide  a  modeling  technique  that  has  the  following  characteristics: 

-  Generic  (for  analysis  of  systems  of  varying  purpose,  scope  and  complexity); 

-  Rigorous  and  precise  (for  production  of  correct,  usable  models); 

-  Concise  (to  facilitate  understanding,  communication,  consensus  and  validation); 

-  Conceptual  (for  representation  of  functional  requirements  rather  than  physical  or  organizational 
implementations); 

-  Flexible  (to  support  several  phases  of  the  life  cycle  of  a  project). 

9.  Applicability. 

The  use  of  this  standard  is  strongly  recommended  for  projects  that: 

a.  Require  a  modeling  technique  for  the  analysis,  development,  re-engineering,  integration,  or  acqui¬ 
sition  of  information  systems; 

b.  Incorporate  a  systems  or  enterprise  modeling  technique  into  a  business  process  analysis  or  soft¬ 
ware  engineering  methodology. 

The  specifications  of  this  standard  are  applicable  when  system  or  enterprise  modeling  techniques  are 
applied  to  the  following: 

a.  Projects  requiring  IDEFO  as  the  modeling  technique; 

b.  Development  of  automated  software  tools  implementing  the  IDEFO  modeling  technique. 

The  specifications  of  this  standard  are  not  applicable  to  those  projects  requiring  a  function  modeling 
technique  other  than  IDEFO. 

Nonstandard  features  of  the  IDEFO  technique  should  be  used  only  when  the  needed  operation  or 
function  cannot  reasonably  be  implemented  with  the  standard  features  alone.  Although  nonstandard 
features  can  be  very  useful,  it  should  be  recognized  that  the  use  of  these  or  any  other  nonstandard  ele¬ 
ments  may  make  the  integration  of  models  more  difficult  and  costly. 

10.  Specifications.  This  standard  adopts  the  Integration  Definition  for  Function  Modeling  (IDEFO)  as  a 
Federal  Information  Processing  Standard  (FIPS). 

1 1 .  Implementation.  The  implementation  of  this  standard  involves  two  areas  of  consideration:  acquisition 
of  implementations  and  interpretation  of  the  standard. 

11.1  Acquisition  of  IDEFO  Implementations.  This  publication  (FIPS  183)  is  effective  June  30, 
1994.  For  Federal  acquisitions  after  this  date,  projects  utilizing  the  IDEFO  function  modeling  technique,  or 
software  implementing  the  IDEFO  modeling  technique,  should  conform  to  FIPS  183.  Conformance  to  this 
standard  should  be  considered  whether  the  project  or  software  utilizing  the  IDEFO  modeling  technique  is 
acquired  as  part  of  an  ADP  system  procurement,  acquired  by  separate  procurement,  used  under  an  ADP 
leasing  arrangement,  or  specified  for  use  in  contracts  for  programming  services. 

A  transition  period  provides  time  for  industry  to  develop  products  conforming  to  this  standard.  The 
transition  period  begins  on  the  effective  date  and  continues  for  one  (1)  year  thereafter.  The  provisions  of 
this  publication  apply  to  orders  placed  after  the  date  of  this  publication;  however,  utilizing  a  function  mod¬ 
eling  technique  that  does  not  conform  to  this  standard  may  be  permitted  during  the  transition  period. 
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1 1 .2  Interpretation  of  this  FIPS.  NIST  provides  for  the  resolution  of  questions  regarding  the  imple¬ 
mentation  and  applicability  of  this  FIPS.  All  questions  concerning  the  interpretation  of  this  standard  should 
be  addressed  to: 

Director,  Computer  Systems  Laboratory 
ATTN:  FIPS  183  Interpretation 
National  Institute  of  Standards  and  Technology 
Gaithersburg,  MD  20899 

12.  Waivers.  Under  certain  exceptional  circumstances,  the  heads  of  Federal  departments  and  agencies 
may  approve  waivers  to  Federal  Information  Processing  Standards  (FIPS).  The  head  of  such  agencies  may 
redelegate  such  authority  only  to  a  senior  official  designated  pursuant  to  section  3506(b)  of  Title  44,  United 
States  Code.  Requests  for  waivers  shall  be  granted  only  when: 

a.  Compliance  with  a  standard  would  adversely  affect  the  accomplishment  of  the  mission  of  an  oper¬ 
ator  of  a  Federal  computer  system,  or 

b.  Compliance  with  a  standard  would  cause  a  major  adverse  financial  impact  on  the  operator  which 
is  not  offset  by  government-wide  savings. 

Agency  heads  may  approve  requests  for  waivers  only  by  a  written  decision  which  explains  the  basis 
upon  which  the  agency  head  made  the  required  finding(s).  A  copy  of  each  such  decision,  with  procurement 
sensitive  or  classified  portions  clearly  identified,  shall  be  sent  to: 

Director,  Computer  Systems  Laboratory 
ATTN:  FIPS  Waiver  Decisions 
National  Institute  of  Standards  and  Technology 
Gaithersburg,  MD  20899 

In  addition,  notice  of  each  waiver  granted  and  each  delegation  of  authority  to  approve  waivers  shall  be 
sent  promptly  to  the  Committee  on  Government  Operations  of  the  House  of  Representatives  and  the  Com¬ 
mittee  on  Governmental  Affairs  of  the  Senate  and  shall  be  published  promptly  in  the  Federal  Register. 

When  the  determination  on  a  waiver  request  applies  to  the  procurement  of  equipment  and/or  services, 
a  notice  of  the  waiver  determination  must  be  published  in  the  Commerce  Business  Daily  as  a  part  of  the 
notice  of  solicitation  for  offers  of  an  acquisition  or,  if  the  waiver  determination  is  made  after  that  notice  is 
published,  by  amendment  of  such  notice. 

A  copy  of  the  waiver  request,  any  supporting  documents,  the  document  approving  the  waiver  request 
and  any  supporting  and  accompanying  documents,  with  such  deletions  as  the  agency  is  authorized  and 
decides  to  make  under  5  U.S.C.  Sec.  552  (b),  shall  be  part  of  the  procurement  documentation  and  retained 
by  the  agency. 

13.  Where  to  Obtain  Copies.  Copies  of  this  publication  are  for  sale  by  the  National  Technical  Informa¬ 
tion  Service,  U.S.  Department  of  Commerce,  Springfield,  VA  22161.  When  ordering,  refer  to  Federal 
Information  Processing  Standards  Publication  183  (FIPSPUB183)  and  title.  Payment  may  be  made  by 
check,  money  order,  or  deposit  account. 
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Introduction: 


This  standard  is  composed  of  normative  and  informative  sections.  Compliance  with  the 
normative  sections  (Sections  1  through  3)  is  required.  The  informative  sections  (Annexes 
A  through  D)  provide  additional  suggestions  and  guidance.  Compliance  with  the 
informative  sections  is  not  required  to  comply  with  the  standard,  unless  such  compliance  is 
stipulated  by  an  organization  adopting  this  standard. 

This  informative  introduction  discusses  the  background  and  approach  of  IDEFO 
(pronounced  I-def  zero).  It  provides  the  reader  with  an  orientation  and  approach  to  the 
normative  sections. 

Background: 

During  the  1970s,  the  U.S.  Air  Force  Program  for  Integrated  Computer  Aided 
Manufacturing  (ICAM)  sought  to  increase  manufacturing  productivity  through  systematic 
application  of  computer  technology.  The  ICAM  program  identified  the  need  for  better 
analysis  and  communication  techniques  for  people  involved  in  improving  manufacturing 
productivity. 

As  a  result,  the  ICAM  program  developed  a  series  of  techniques  known  as  the  IDEF 
(ICAM  Definition)  techniques  which  included  the  following: 

1.  IDEFO,  used  to  produce  a  "function  model".  A  function  model  is  a 
structured  representation  of  the  functions,  activities  or  processes  within  the 
modeled  system  or  subject  area. 

2.  IDEF1,  used  to  produce  an  "information  model".  An  information  model 
represents  the  structure  and  semantics  of  information  within  the  modeled 
system  or  subject  area. 

3.  IDEF2,  used  to  produce  a  "dynamics  model".  A  dynamics  model 
represents  the  time-varying  behavioral  characteristics  of  the  modeled  system 
or  subject  area. 

In  1983,  the  U.S.  Air  Force  Integrated  Information  Support  System  program  enhanced  the 
IDEF1  information  modeling  technique  to  form  IDEF  IX  (IDEF1  Extended),  a  semantic 
data  modeling  technique. 

Currently,  IDEFO  and  IDEF IX  techniques  are  widely  used  in  the  government,  industrial 
and  commercial  sectors,  supporting  modeling  efforts  for  a  wide  range  of  enterprises  and 
application  domains. 

In  1991  the  National  Institute  of  Standards  and  Technology  (NIST)  received  support  from 
the  U.S.  Department  of  Defense,  Office  of  Corporate  Information  Management 
(DoD/CIM),  to  develop  one  or  more  Federal  Information  Processing  Standards  (FIPS)  for 
modeling  techniques.  The  techniques  selected  were  IDEFO  for  function  modeling  and 
IDEF  IX  for  information  modeling.  These  FIPS  documents  are  based  on  the  IDEF 
manuals  published  by  the  U.S.  Air  Force  in  the  early  1980s. 


The  IDEFO  Approach: 


IDEFO  (Integration  DEFinition  language  0)  is  based  on  SADT™  (Structured  Analysis  and 

Design  Technique™),  developed  by  Douglas  T.  Ross  and  SofTech,  Inc.  In  its  original 
form,  IDEFO  includes  both  a  definition  of  a  graphical  modeling  language  (syntax  and 
semantics)  and  a  description  of  a  comprehensive  methodology  for  developing  models. 

IDEFO  may  be  used  to  model  a  wide  variety  of  automated  and  non-automated  systems.  For 
new  systems,  IDEFO  may  be  used  first  to  define  the  requirements  and  specify  the 
functions,  and  then  to  design  an  implementation  that  meets  the  requirements  and  performs 
the  functions.  For  existing  systems,  IDEFO  can  be  used  to  analyze  the  functions  the 
system  performs  and  to  record  the  mechanisms  (means)  by  which  these  are  done. 

The  result  of  applying  IDEFO  to  a  system  is  a  model  that  consists  of  a  hierarchical  series  of 
diagrams,  text,  and  glossary  cross-referenced  to  each  other.  The  two  primary  modeling 
components  are  functions  (represented  on  a  diagram  by  boxes)  and  the  data  and  objects  that 
inter-relate  those  functions  (represented  by  arrows). 

As  a  function  modeling  language,  IDEFO  has  the  following  characteristics: 

1 .  It  is  comprehensive  and  expressive,  capable  of  graphically  representing  a 
wide  variety  of  business,  manufacturing  and  other  types  of  enterprise 
operations  to  any  level  of  detail. 

2.  It  is  a  coherent  and  simple  language,  providing  for  rigorous  and  precise 
expression,  and  promoting  consistency  of  usage  and  interpretation. 

3 .  It  enhances  communication  between  systems  analysts,  developers  and  users 
through  ease  of  learning  and  its  emphasis  on  hierarchical  exposition  of 
detail. 

4.  It  is  well-tested  and  proven,  through  many  years  of  use  in  Air  Force  and 
other  government  development  projects,  and  by  private  industry. 

5.  It  can  be  generated  by  a  variety  of  computer  graphics  tools;  numerous 
commercial  products  specifically  support  development  and  analysis  of 
IDEFO  diagrams  and  models. 

In  addition  to  definition  of  the  IDEFO  language,  the  IDEFO  methodology  also  prescribes 
procedures  and  techniques  for  developing  and  interpreting  models,  including  ones  for  data 
gathering,  diagram  construction,  review  cycles  and  documentation.  Materials  related  solely 
to  modeling  procedures  are  presented  in  the  informative  annexes  of  this  document. 
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1.  Overview 


1.1  Scope 

This  standard  describes  the  modeling  language  (syntax  and  semantics)  which  supports  the 
IDEFO  technique  for  developing  structured  graphical  representations  of  a  system  or  subject 
area.  Use  of  this  standard  permits  the  construction  of  IDEFO  models  comprising  system 
functions  (actions,  processes,  operations),  functional  relationships,  and  the  data  and 
objects  that  support  systems  analysis  and  design,  enterprise  analysis,  and  business  process 
re-engineering. 

This  document  provides  three  normative  sections,  Sections  1,  2  and  3,  which  define  the 
language  that  supports  IDEFO  modeling.  This  section,  Section  1,  provides  an  overview  of 
the  document.  Section  2  defines  the  key  terms  used  in  the  normative  sections.  Section  3 
defines  the  syntax  and  semantics  of  the  language. 

In  addition  to  the  three  normative  sections,  this  document  also  provides  four  informative 
annexes.  Annex  A  discusses  the  concepts  that  underlie  IDEFO.  Annex  B  provides 
guidelines  for  creating,  interpreting  and  gathering  data  for  IDEFO  diagrams.  Annex  C 
describes  structured  team-oriented  procedures  (including  forms)  for  IDEFO  model  review 
and  validation.  Annex  D  defines  the  key  terms  used  in  the  annexes. 

This  standard  covers  IDEFO  as  defined  by  the  U.S.  Air  Force  Integrated  Computer-Aided 
Manufacturing  (ICAM)  Function  Modeling  Manual  (IDEFO).  June  1981,  and  commonly 
practiced  by  many  IDEF  users  since  then. 

1.2  Purpose 

The  primary  objectives  of  this  standard  are: 

1.  To  document  and  clarify  the  IDEFO  modeling  technique  and  how  to 
correctly  use  it; 

2.  To  provide  a  means  for  completely  and  consistently  modeling  the  functions 
required  by  a  system  or  subject  area,  and  the  data  and  objects  that  inter¬ 
relate  those  functions; 

3 .  To  provide  a  modeling  language  which  is  independent  of  Computer-Aided 
Software  Engineering  (CASE)  methods  or  tools,  but  which  can  be  used  in 
conjunction  with  those  methods  or  tools; 

4 .  To  provide  a  modeling  language  that  has  the  following  characteristics: 

a)  Generic  (for  analysis  of  systems  and  subject  areas  of  varying 
purpose,  scope  and  complexity); 

b)  Rigorous  and  precise  (for  production  of  correct,  usable  models); 

c)  Concise  (to  facilitate  understanding,  communication,  consensus  and 
validation); 

d)  Conceptual  (for  representation  of  functional  requirements 
independent  of  physical  or  organizational  implementations); 

e)  Flexible  (to  support  several  phases  of  the  life  cycle  of  a  project). 
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2.  Definitions 


This  section  contains  definitions  that  relate  to  the  normative  sections  of  this  document.  See 
Annex  D  for  definitions  for  the  informative  annexes.  A  term,  if  defined,  is  defined  in  either 
Section  2  or  Annex  D. 

2 . 1  A-0  Diagram:  The  special  case  of  a  one-box  IDEFO  context  diagram,  containing 
the  top-level  function  being  modeled  and  its  inputs,  controls,  outputs  and  mechanisms, 
along  with  statements  of  model  purpose  and  viewpoint. 

2 . 2  Arrow:  A  directed  line,  composed  of  one  or  more  arrow  segments,  that  models  an 
open  channel  or  conduit  conveying  data  or  objects  from  source  (no  arrowhead)  to  use  (with 
arrowhead).  There  are  4  arrow  classes:  Input  Arrow,  Output  Arrow,  Control  Arrow,  and 
Mechanism  Arrow  (includes  Call  Arrow).  See  Arrow  Segment,  Boundary  Arrow,  Internal 
Arrow. 

2.3  Arrow  Label:  A  noun  or  noun  phrase  associated  with  an  IDEFO  arrow  or  arrow 
segment,  specifying  its  meaning. 

2.4  Arrow  Segment:  A  line  segment  that  originates  or  terminates  at  a  box  side,  a 
branch  (fork  or  join),  or  a  boundary  (unconnected  end). 

2 . 5  Boundary  Arrow:  An  arrow  with  one  end  (source  or  use)  not  connected  to  any 
box  on  a  diagram.  Contrast  with  Internal  Arrow. 

2 . 6  Box:  A  rectangle,  containing  a  name  and  number,  used  to  represent  a  function. 

2.7  Box  Name:  The  verb  or  verb  phrase  placed  inside  an  IDEFO  box  to  describe  the 
modeled  function. 

2 . 8  Box  Number:  The  number  (0  to  6)  placed  inside  the  lower  right  corner  of  an 
IDEFO  box  to  uniquely  identify  the  box  on  a  diagram. 

2 . 9  Branch:  A  junction  (fork  or  join)  of  two  or  more  arrow  segments. 

2.10  Bundling/Unbundling:  The  combining  of  arrow  meanings  into  a  composite 
meaning  (bundling),  or  the  separation  of  arrow  meanings  (unbundling),  expressed  by 
arrow  join  and  fork  syntax. 

2.11  C-Number:  A  chronological  creation  number  that  may  be  used  to  uniquely  identify 
a  diagram  and  to  trace  its  history;  may  be  used  as  a  Detail  Reference  Expression  to  specify  a 
particular  version  of  a  diagram. 

2.12  Call  Arrow:  A  type  of  mechanism  arrow  that  enables  the  sharing  of  detail  between 
models  (linking  them  together)  or  within  a  model. 

2.13  Child  Box:  A  box  on  a  child  diagram. 

2.14  Child  Diagram:  The  diagram  that  details  a  parent  box. 

2.15  Context:  The  immediate  environment  in  which  a  function  (or  set  of  functions  on  a 
diagram)  operates. 
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2.16  Context  Diagram:  A  diagram  that  presents  the  context  of  a  model,  whose  node 
number  is  A-n  (n  greater  than  or  equal  to  zero).  The  one-box  A-0  diagram  is  a  required 
context  diagram;  those  with  node  numbers  A-l,  A-2, ...  are  optional  context  diagrams. 

2.17  Control  Arrow:  The  class  of  arrows  that  express  IDEFO  Control,  i.e.,  conditions 
required  to  produce  correct  output.  Data  or  objects  modeled  as  controls  may  be 
transformed  by  the  function,  creating  output.  Control  arrows  are  associated  with  the  top 
side  of  an  IDEFO  box. 

2.18  Decomposition:  The  partitioning  of  a  modeled  function  into  its  component 
functions. 

2.19  Detail  Reference  Expression  (DRE):  A  reference  (e.g.,  node  number,  C- 
number,  page  number)  written  beneath  the  lower  right  comer  of  an  IDEFO  box  to  show  that 
it  is  detailed  and  to  indicate  which  diagram  details  it. 

2.20  Diagram:  A  single  unit  of  an  IDEFO  model  that  presents  the  details  of  a  box. 

2.21  Diagram  Node  Number:  That  part  of  a  diagram's  node  reference  that 
corresponds  to  its  parent  box  node  number. 

2.22  For  Exposition  Only  (FEO)  Diagram:  A  graphic  description  used  to  expose  or 
highlight  specific  facts  about  an  IDEFO  diagram.  Unlike  an  IDEFO  graphic  diagram,  a  FEO 
diagram  need  not  comply  with  IDEFO  rules. 

2.23  Fork:  The  junction  at  which  an  IDEFO  arrow  segment  (going  from  source  to  use) 
divides  into  two  or  more  arrow  segments.  May  denote  unbundling  of  meaning. 

2.24  Function:  An  activity,  process,  or  transformation  (modeled  by  an  IDEFO  box) 
identified  by  a  verb  or  verb  phrase  that  describes  what  must  be  accomplished. 

2.25  Function  Name:  Same  as  Box  Name. 

2.26  Glossary:  A  listing  of  definitions  for  key  words,  phrases  and  acronyms  used  in 
conjunction  with  an  IDEFO  node  or  model  as  a  whole. 

2.27  ICOM  Code:  The  acronym  of  Input,  Control,  Output,  Mechanism.  A  code  that 
associates  the  boundary  arrows  of  a  child  diagram  with  the  arrows  of  its  parent  box;  also 
used  for  reference  purposes. 

2.28  IDEFO  Model:  A  graphic  description  of  a  system  or  subject  that  is  developed  for  a 
specific  purpose  and  from  a  selected  viewpoint.  A  set  of  one  or  more  IDEFO  diagrams  that 
depict  the  functions  of  a  system  or  subject  area  with  graphics,  text  and  glossary. 

2.29  Input  Arrow:  The  class  of  arrows  that  express  IDEFO  Input,  i.e.,  the  data  or 
objects  that  are  transformed  by  the  function  into  output.  Input  arrows  are  associated  with 
the  left  side  of  an  IDEFO  box. 

2.30  Interface:  A  shared  boundary  across  which  data  or  objects  are  passed;  the 
connection  between  two  or  more  model  components  for  the  purpose  of  passing  data  or 
objects  from  one  to  the  other. 

2.31  Internal  Arrow:  An  input,  control  or  output  arrow  connected  at  both  ends  (source 
and  use)  to  a  box  on  a  diagram.  Contrast  with  Boundary  Arrow. 


3 


2.32  Join:  The  junction  at  which  an  IDEFO  arrow  segment  (going  from  source  to  use) 
merges  with  one  or  more  other  arrow  segments  to  form  a  single  arrow  segment.  May 
denote  bundling  of  arrow  segment  meanings. 

2.33  Mechanism  Arrow:  The  class  of  arrows  that  express  IDEFO  Mechanism,  i.e.,  the 
means  used  to  perform  a  function;  includes  the  special  case  of  Call  Arrow.  Mechanism 
arrows  are  associated  with  the  bottom  side  of  an  IDEFO  box. 

2.34  Model  Note:  A  textual  comment  that  is  part  of  an  IDEFO  diagram,  used  to  record  a 
fact  not  otherwise  depicted. 

2.35  Node:  A  box  from  which  child  boxes  originate;  a  parent  box.  See  Node  Index, 
Node  Tree,  Node  Number,  Node  Reference,  Diagram  Node  Number. 

2.36  Node  Index:  A  listing,  often  indented,  showing  nodes  in  an  IDEFO  model  in 
"outline"  order.  Same  meaning  and  content  as  Node  Tree. 

2.37  Node  Number:  A  code  assigned  to  a  box  to  specify  its  position  in  the  model 
hierarchy;  may  be  used  as  a  Detail  Reference  Expression. 

2.38  Node  Reference:  A  code  assigned  to  a  diagram  to  identify  it  and  specify  its 
position  in  the  model  hierarchy;  composed  of  the  model  name  (abbreviated)  and  the 
diagram  node  number,  with  optional  extensions. 

2.39  Node  Tree:  The  graphical  representation  of  the  parent-child  relationships  between 
the  nodes  of  an  IDEFO  model,  in  the  form  of  a  graphical  tree.  Same  meaning  and  content 
as  Node  Index. 

2.40  Output  Arrow:  The  class  of  arrows  that  express  IDEFO  Output,  i.e.,  the  data  or 
objects  produced  by  a  function.  Output  arrows  are  associated  with  the  right  side  of  an 
IDEFO  box. 

2.41  Parent  Box:  A  box  that  is  detailed  by  a  child  diagram. 

2.42  Parent  Diagram:  A  diagram  that  contains  a  parent  box. 

2.43  Purpose:  A  brief  statement  of  the  reason  for  a  model's  existence. 

2.44  Semantics:  The  meaning  of  the  syntactic  components  of  a  language. 

2.45  Squiggle:  A  small  jagged  line  that  may  be  used  to  associate  a  label  with  a  particular 
arrow  segment  or  to  associate  a  model  note  with  a  component  of  a  diagram. 

2.46  Syntax:  Structural  components  or  features  of  a  language  and  the  rules  that  define 
relationships  among  them. 

2.47  Text:  An  overall  textual  (non-graphical)  comment  about  an  IDEFO  graphic  diagram. 

2.48  Title:  A  verb  or  verb  phrase  that  describes  the  overall  function  presented  on  an 
IDEFO  diagram;  the  title  of  a  child  diagram  corresponds  to  its  parent  box  name. 

2.49  Tunneled  Arrow:  An  arrow  (with  special  notation)  that  does  not  follow  the 
normal  requirement  that  each  arrow  on  a  diagram  must  correspond  to  arrows  on  related 
parent  and  child  diagrams. 

2.50  Viewpoint:  A  brief  statement  of  the  perspective  of  the  model. 
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3.  IDEFO  Models 


This  section  discusses  the  basic  elements  of  the  IDEFO  modeling  technique,  identifies  the 
basic  components  of  syntax  (graphical  component)  and  semantics  (meaning),  specifies  the 
rules  that  govern  the  use  of  the  IDEFO  technique,  and  describes  the  types  of  diagrams  used. 
Although  the  components  of  syntax  and  semantics  are  very  highly  interrelated,  each  one  is 
discussed  separately  without  regard  for  the  actual  sequence  of  construction. 

3.1  Model  Concepts 

A  model  is  a  representation  of  a  set  of  components  of  a  system  or  subject  area.  The  model 
is  developed  for  understanding,  analysis,  improvement  or  replacement  of  the  system. 
Systems  are  composed  of  interfacing  or  interdependent  parts  that  work  together  to  perform 
a  useful  function.  System  parts  can  be  any  combination  of  things,  including  people, 
information,  software,  processes,  equipment,  products,  or  raw  materials.  The  model 
describes  what  a  system  does,  what  controls  it,  what  things  it  works  on,  what  means  it 
uses  to  perform  its  functions,  and  what  it  produces. 

IDEFO  is  a  modeling  technique  based  on  combined  graphics  and  text  that  are  presented  in 
an  organized  and  systematic  way  to  gain  understanding,  support  analysis,  provide  logic 
for  potential  changes,  specify  requirements,  or  support  systems  level  design  and  integration 
activities.  An  IDEFO  model  is  composed  of  a  hierarchical  series  of  diagrams  that  gradually 
display  increasing  levels  of  detail  describing  functions  and  their  interfaces  within  the 
context  of  a  system.  There  are  three  types  of  diagrams:  graphic,  text,  and  glossary.  The 
graphic  diagrams  define  functions  and  functional  relationships  via  box  and  arrow  syntax 
and  semantics.  The  text  and  glossary  diagrams  provide  additional  information  in  support 
of  graphic  diagrams. 

IDEFO  is  an  engineering  technique  for  performing  and  managing  needs  analysis,  benefits 
analysis,  requirements  definition,  functional  analysis,  systems  design,  maintenance,  and 
baselines  for  continuous  improvement.  IDEFO  models  provide  a  "blueprint"  of  functions 
and  their  interfaces  that  must  be  captured  and  understood  in  order  to  make  systems 
engineering  decisions  that  are  logical,  affordable,  integratable  and  achievable.  The  IDEFO 
model  reflects  how  system  functions  interrelate  and  operate  just  as  the  blueprint  of  a 
product  reflects  how  the  different  pieces  of  a  product  fit  together.  When  used  in  a 
systematic  way,  IDEFO  provides  a  systems  engineering  approach  to: 

1 .  Performing  systems  analysis  and  design  at  all  levels,  for  systems  composed 
of  people,  machines,  materials,  computers  and  information  of  all  varieties  - 
the  entire  enterprise,  a  system,  or  a  subject  area; 

2 .  Producing  reference  documentation  concurrent  with  development  to  serve  as 
a  basis  for  integrating  new  systems  or  improving  existing  systems; 

3 .  Communicating  among  analysts,  designers,  users,  and  managers; 

4 .  Allowing  coalition  team  consensus  to  be  achieved  by  shared  understanding; 

5.  Managing  large  and  complex  projects  using  qualitative  measures  of 
progress; 

6.  Providing  a  reference  architecture  for  enterprise  analysis,  information 
engineering  and  resource  management. 
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Further  discussion  of  concepts,  philosophy,  and  roles  for  participants  in  IDEFO  modeling 
projects  is  presented  in  the  informative  annexes  of  this  document. 

3.2  Syntax  and  Semantics 

3.2.1  Syntax 

The  structural  components  and  features  of  a  language  and  the  rules  that  define  relationships 
among  them  are  referred  to  as  the  language's  syntax.  The  components  of  the  IDEFO  syntax 
are  boxes  and  arrows,  rules,  and  diagrams.  Boxes  represent  functions,  defined  as 
activities,  processes  or  transformations.  Arrows  represent  data  or  objects  related  to 
functions.  Rules  define  how  the  components  are  used,  and  the  diagrams  provide  a  format 
for  depicting  models  both  verbally  and  graphically.  The  format  also  provides  the  basis  for 
model  configuration  management. 

3.2. 1.1  Boxes 

A  box  provides  a  description  of  what  happens  in  a  designated  function.  A  typical  box  is 
shown  in  Figure  1.  Each  box  shall  have  a  name  and  number  inside  the  box  boundaries. 
The  name  shall  be  an  active  verb  or  verb  phrase  that  describes  the  function.  Each  box  on 
the  diagram  shall  contain  a  box  number  inside  the  lower  right  corner.  Box  numbers  are 
used  to  identify  the  subject  box  in  the  associated  text. 


DEVELOP 

MODEL 
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•  Function  name  is  a  verb  or 
a  verb  phrase. 

•  A  box  number  is  shown. 


Figure  1.  Box  Syntax 


3. 2. 1.2  Arrows 

An  arrow  is  composed  of  one  or  more  line  segments,  with  a  terminal  arrowhead  at  one  end. 
As  shown  in  Figure  2,  arrow  segments  may  be  straight  or  curved  (with  a  90°  arc 
connecting  horizontal  and  vertical  parts),  and  may  have  branching  (forking  or  joining) 
configurations.  Arrows  do  not  represent  flow  or  sequence  as  in  the  traditional  process 
flow  model.  Arrows  convey  data  or  objects  related  to  functions  to  be  performed.  The 
functions  receiving  data  or  objects  are  constrained  by  the  data  or  objects  made  available. 
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•  Straight  line  arrow  segment 


•  Curved  arrow  segment;  corners 
are  rounded  with  90  degree  arcs 


Forking  arrows 


•  Joining  arrows 


Figure  2.  Arrow  Syntax 


3.2. 1.3  Syntax  Rules 

Boxes 

1 .  Boxes  shall  be  sufficient  in  size  to  insert  box  name. 

2.  Boxes  shall  be  rectangular  in  shape,  with  square  corners. 

3 .  Boxes  shall  be  drawn  with  solid  lines. 

Arrows 

1 .  Arrows  that  bend  shall  be  curved  using  only  90  degree  arcs. 

2.  Arrows  shall  be  drawn  in  solid  line  segments. 

3  Arrows  shall  be  drawn  vertically  or  horizontally,  not  diagonally. 

4.  Arrow  ends  shall  touch  the  outer  perimeter  of  the  function  box  and  shall 

not  cross  into  the  box. 

5 .  Arrows  shall  attach  at  box  sides,  not  at  comers. 

3.2.2  Semantics 

Semantics  refers  to  the  meaning  of  syntactic  components  of  a  language  and  aids  correctness 
of  interpretation.  Interpretation  addresses  items  such  as  box  and  arrow  notation  and 
functional  relationship  interfaces. 

3.2.2. 1  Box  and  Arrow  Semantics 

Since  IDEFO  supports  function  modeling,  the  box  name  shall  be  a  verb  or  verb  phrase, 
such  as  “Perform  Inspection”,  that  is  descriptive  of  the  function  that  the  box  represents. 
The  example  "Perform  Inspection"  function  transforms  uninspected  parts  into  inspected 
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parts.  The  definitive  step  beyond  the  phrase-naming  of  the  box  is  the  incorporation  of 
arrows  (matching  the  orientation  of  the  box  sides)  that  complement  and  complete  the 
expressive  power  (as  distinguished  from  the  representational  aspect)  of  the  IDEFO  box. 

Standard  terminology  shall  be  used  to  ensure  precise  communication.  Box  meanings  are 
named — descriptively — with  verbs  or  verb  phrases  and  are  split  and  clustered  in 
decomposition  diagramming.  Arrow  meanings  are  bundled  and  unbundled  in  diagramming 
and  the  arrow  segments  are  labeled  with  nouns  or  noun  phrases  to  express  meanings. 
Arrow-segment  labels  are  prescriptive,  constraining  the  meaning  of  their  segment  to  apply 
exclusively  to  the  particular  data  or  objects  that  the  arrow  segment  graphically  represents. 
Arrow  meanings  are  further  expressed  through  fork  and  join  syntax. 

Each  side  of  the  function  box  has  a  standard  meaning  in  terms  of  box/arrow  relationships. 
The  side  of  the  box  with  which  an  arrow  interfaces  reflects  the  arrow's  role.  Arrows 
entering  the  left  side  of  the  box  are  inputs.  Inputs  are  transformed  or  consumed  by  the 
function  to  produce  outputs.  Arrows  entering  the  box  on  the  top  are  controls.  Controls 
specify  the  conditions  required  for  the  function  to  produce  correct  outputs.  Arrows  leaving 
a  box  on  the  right  side  are  outputs.  Outputs  are  the  data  or  objects  produced  by  the 
function. 

Arrows  connected  to  the  bottom  side  of  the  box  represent  mechanisms.  Upward  pointing 
arrows  identify  some  of  the  means  that  support  the  execution  of  the  function.  Other  means 
may  be  inherited  from  the  parent  box.  Mechanism  arrows  that  point  downward  are  call 
arrows.  Call  arrows  enable  the  sharing  of  detail  between  models  (linking  them  together)  or 
between  portions  of  the  same  model.  The  called  box  provides  detail  for  the  caller  box  (see 
Section  3.3.2.10). 

Standard  arrow  positions  are  shown  in  Figure  3. 

Supporting  information  concerning  the  function  and  its  purpose  shall  be  addressed  in  the 
text  associated  with  the  diagram.  A  diagram  may  or  may  not  have  associated  text.  When 
acronyms,  abbreviations,  key  words,  or  phrases  are  used,  the  fully  defined  term(s)  shall  be 
provided  in  the  glossary. 
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Figure  3.  Arrow  Positions  and  Roles 
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3. 2.2. 2  Labels  and  Names 


Boxes  represent  functions  that  show  what  must  be  accomplished.  A  function  name  shall  be 
an  active  verb  or  verb  phrase,  such  as: 

process  parts  plan  resources  conduct  review 

monitor  performance  design  system  provide  maintenance 

develop  detail  design  fabricate  component  inspect  part 

The  arrows  identify  data  or  objects  needed  or  produced  by  the  function.  Each  arrow  shall 
be  labeled  with  a  noun  or  noun  phrase,  such  as: 

specifications  test  report  budget 

design  requirements  detail  design  directive 

design  engineer  board  assembly  requirements 


An  example  depicting  the  placement  of  arrow  labels  and  box  names  is  shown  in  Figure  4. 
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Figure  4.  Label  and  Name  Semantics 


3.2. 2.3  Box  and  Arrow  Semantic  Rules 


1 .  A  box  shall  be  named  with  an  active  verb  or  verb  phrase. 

2 .  Each  side  of  a  function  box  shall  have  a  standard  box/arrow  relationship: 

a)  Input  arrows  shall  interface  with  the  left  side  of  a  box. 

b)  Control  arrows  shall  interface  with  the  top  side  of  a  box. 

c)  Output  arrows  shall  interface  with  the  right  side  of  the  box. 

d)  Mechanism  arrows  (except  call  arrows)  shall  point  upward  and  shall 
connect  to  the  bottom  side  of  the  box. 

e)  Mechanism  call  arrows  shall  point  downward,  shall  connect  to  the 
bottom  side  of  the  box,  and  shall  be  labeled  with  the  reference 
expression  for  the  box  which  details  the  subject  box. 
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3.  Arrow  segments,  except  for  call  arrows,  shall  be  labeled  with  a  noun  or 
noun  phrase  unless  a  single  arrow  label  clearly  applies  to  the  arrow  as  a 
whole. 

4.  A  “squiggle”  ( )  shall  be  used  to  link  an  arrow  with  its  associated 
label,  unless  the  arrow/label  relationship  is  obvious. 

5.  Arrow  labels  shall  not  consist  solely  of  any  of  the  following  terms: 
function,  input,  control,  output,  mechanism,  or  call. 

3.3  IDEFO  Diagrams 

3.3.1  Types  of  Diagrams 

IDEFO  models  are  composed  of  three  types  of  information:  graphic  diagrams,  text,  and 
glossary.  These  diagram  types  are  cross-referenced  to  each  other.  The  graphic  diagram  is 
the  major  component  of  an  IDEFO  model,  containing  boxes,  arrows,  box/arrow 
interconnections  and  associated  relationships.  Boxes  represent  each  major  function  of  a 
subject.  These  functions  are  broken  down  or  decomposed  into  more  detailed  diagrams, 
until  the  subject  is  described  at  a  level  necessary  to  support  the  goals  of  a  particular  project. 
The  top-level  diagram  in  the  model  provides  the  most  general  or  abstract  description  of  the 
subject  represented  by  the  model.  This  diagram  is  followed  by  a  series  of  child  diagrams 
providing  more  detail  about  the  subject. 

3.3. 1.1  Top-Level  Context  Diagram 

Each  model  shall  have  a  top-level  context  diagram,  on  which  the  subject  of  the  model  is 
represented  by  a  single  box  with  its  bounding  arrows.  This  is  called  the  A-0  diagram 
(pronounced  A  minus  zero).  The  arrows  on  this  diagram  interface  with  functions  outside 
the  subject  area  to  establish  model  focus.  Since  a  single  box  represents  the  whole  subject, 
the  descriptive  name  written  in  the  box  is  general.  The  same  is  true  of  the  interface  arrows 
since  they  also  represent  the  complete  set  of  external  interfaces  to  the  subject.  The  A-0 
diagram  also  sets  the  model  scope  or  boundary  and  orientation.  An  example  A-0  diagram 
is  shown  in  Figure  5. 

The  A-0  context  diagram  also  shall  present  brief  statements  specifying  the  model's 
viewpoint  and  purpose,  which  help  to  guide  and  constrain  the  creation  of  the  model.  The 
viewpoint  determines  what  can  be  "seen"  within  the  model  context,  and  from  what 
perspective  or  "slant".  Depending  on  the  audience,  different  statements  of  viewpoint  may 
be  adopted  that  emphasize  different  aspects  of  the  subject.  Things  that  are  important  in  one 
viewpoint  may  not  even  appear  in  a  model  presented  from  another  viewpoint  of  the  same 
subject. 

The  statement  of  purpose  expresses  the  reason  why  the  model  is  created  and  actually 
determines  the  structure  of  the  model.  The  most  important  features  come  first  in  the 
hierarchy,  as  the  whole  top-level  function  is  decomposed  into  sub-function  parts  that 
compose  it,  and  those  parts,  in  turn,  are  further  decomposed  until  all  of  the  relevant  detail 
of  the  whole  viewpoint  is  adequately  exposed.  Each  sub-function  is  modeled  individually 
by  a  box,  with  parent  boxes  detailed  by  child  diagrams  at  the  next  lower  level.  All  child 
diagrams  must  be  within  the  scope  of  the  top-level  context  diagram. 
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Figure  5.  Example  Top-level  Diagram 


3.3. 1.2  Child  Diagram 

The  single  function  represented  on  the  top-level  context  diagram  may  be  decomposed  into 
its  major  sub-functions  by  creating  its  child  diagram.  In  turn,  each  of  these  sub-functions 
may  be  decomposed,  each  creating  another,  lower-level  child  diagram.  On  a  given 
diagram,  some  of  the  functions,  none  of  the  functions  or  all  of  the  functions  may  be 
decomposed.  Each  child  diagram  contains  the  child  boxes  and  arrows  that  provide 
additional  detail  about  the  parent  box. 

The  child  diagram  that  results  from  the  decomposition  of  a  function  covers  the  same  scope 
as  the  parent  box  it  details.  Thus,  a  child  diagram  may  be  thought  of  as  being  the  "inside" 
of  its  parent  box.  This  structure  is  illustrated  in  Figure  6. 

3.3. 1.3  Parent  Diagram 

A  parent  diagram  is  one  that  contains  one  or  more  parent  boxes.  Every  ordinary  (non¬ 
context)  diagram  is  also  a  child  diagram,  since  by  definition  it  details  a  parent  box.  Thus  a 
diagram  may  be  both  a  parent  diagram  (containing  parent  boxes)  and  a  child  diagram 
(detailing  its  own  parent  box).  Likewise,  a  box  may  be  both  a  parent  box  (detailed  by  a 
child  diagram)  and  a  child  box  (appearing  on  a  child  diagram).  The  primary  hierarchical 
relationship  is  between  a  parent  box  and  the  child  diagram  that  details  it. 
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The  fact  that  a  child  box  is  detailed,  and  is  therefore  also  a  parent  box,  is  indicated  by  the 
presence  of  a  Detail  Reference  Expression  (DRE).  The  DRE  is  a  short  code  written  below 
the  lower  right  comer  of  the  detailed  (parent)  box  that  points  to  its  child  diagram. 

The  DRE  shall  take  one  of  the  following  forms: 

1 .  A  chronological  creation  number  called  a  "C-number"  that  shall  uniquely 
identify  a  particular  version  of  a  child  diagram. 

2.  A  page  number  of  the  child  diagram  in  the  published  document  in  which  the 
model  appears. 

3.  The  node  number  referencing  the  child  diagram.  If  there  are  multiple 
versions  of  a  child  diagram,  a  particular  version  cannot  be  specified. 

4.  A  model  note  number  whose  text  specifies  the  conditions  for  selection  of  a 
particular  child  version. 

Figure  7  illustrates  the  use  of  node  numbers  as  DREs.  In  the  figure,  the  presence  of  DREs 
under  boxes  1,  2  and  3  indicates  that  they  have  been  detailed  on  the  specified  child 
diagrams. 


C2  Cl  C3 
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Figure  7.  Detail  Reference  Expression  Use 


3.3. 1.4  Text  and  Glossary 

A  diagram  may  have  associated  structured  text,  which  is  used  to  provide  a  concise 
overview  of  the  diagram.  Text  shall  be  used  to  highlight  features,  flows,  and  inter-box 
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connections  to  clarify  the  intent  of  items  and  patterns  considered  to  be  of  significance.  Text 
shall  not  be  used  merely  to  describe,  redundantly,  the  meaning  of  boxes  and  arrows. 

The  glossary  shall  be  used  to  define  acronyms  and  key  words  and  phrases  that  have  been 
used  in  conjunction  with  diagram  graphics.  The  glossary  defines  words  in  the  model  that 
must  convey  a  common  understanding  in  order  to  correctly  interpret  the  model  content. 

3.3. 1.5  For  Exposition  Only  Diagrams 

For  Exposition  Only  (FEO,  pronounced  fee-oh)  diagrams  shall  be  used  where  an  additional 
level  of  supplementary  knowledge  is  required  to  adequately  understand  specific  areas  of  a 
model.  Supplementary  detailing  should  be  limited  to  what  is  needed  to  achieve  the  stated 
purpose  for  a  knowledgeable  audience.  A  FEO  diagram  need  not  comply  with  IDEFO 
syntax  rules. 

3.3.2  Diagram  Features 
3.3.2. 1  Arrows  as  Constraints 

Arrows  on  an  IDEFO  diagram  represent  data  or  objects  as  constraints.  Only  at  low  levels 
of  detail  can  arrows  represent  flow  or  sequence,  when  the  modeled  subject  is  sufficiently 
detailed  to  treat  specific  changes  made  to  specific  data  items  or  objects.  Connecting  the 
output  of  one  box  to  the  input,  control,  or  mechanism  of  another  box  shows  that  the 
function  modeled  by  the  latter  box  requires,  and  thus  is  constrained  by,  the  presence  of  the 
corresponding  output  of  the  former  box.  This  type  of  constraint  is  illustrated  in  Figure  8. 
The  arrows  connecting  to  a  box  represent  all  the  data  and  objects  that  are  needed  for  the 
function  to  be  completely  performed. 


Figure  8.  Meaning  of  Constraint 
3. 3. 2. 2  Activations  of  a  Box 

A  box  may  perform  various  parts  of  its  function  under  different  circumstances,  using 
different  combinations  of  its  input  and  controls  and  producing  different  outputs.  These 
different  performances  are  called  the  different  activations  of  the  box. 
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3. 3.2. 3  Concurrent  Operation 

Several  functions  in  a  model  may  be  performed  concurrently,  if  the  needed  constraints  have 
been  satisfied.  As  illustrated  in  Figure  9,  an  output  of  one  box  may  provide  some  or  all  of 
the  data  and  objects  needed  for  activations  of  one  or  more  other  boxes. 

When  an  output  of  one  box  provides  some  or  all  of  the  inputs,  controls  or  mechanisms 
needed  by  another  box,  a  given  activation  of  the  latter  box  may  depend  on  sequential 
performance.  However,  different  activations  of  the  same  box(es),  with  possibly  different 
requirements,  may  operate  concurrently. 


Figure  9.  Concurrent  Operation 


3. 3. 2.4  Arrows  as  Pipelines 

It  is  useful  to  think  of  high-level  arrows  as  pipelines  or  conduits.  High-level  arrows  have 
general  labels,  while  arrows  on  lower-level  diagrams  have  more  specific  labels.  If  an 
arrow  splits,  forming  two  or  more  new  arrow  segments,  each  arrow  segment  may  have  a 
more  specific  label,  as  shown  in  Figure  10. 


Figure  10.  Arrow  Pipeline  with  Forking 
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3.3. 2. 5  Branching  Arrows 

An  arrow  may  branch  (fork  or  join),  indicating  that  the  same  kind  of  data  or  object  may  be 
needed  or  produced  by  more  than  one  function.  The  branches  may  represent  either  the 
same  thing  or  portions  of  the  same  thing.  Since  labels  specify  what  arrow  segments 
represent,  labels  on  branching  arrow  segments  provide  a  detailing  of  the  arrow  content  just 
as  lower  level  diagrams  provide  detailing  of  parent  boxes. 

All  or  part  of  the  contents  of  an  arrow  may  follow  a  branch.  A  forking  arrow  may  denote 
the  "unbundling"  of  meanings  that  had  been  combined  under  a  more  general  label.  The 
joining  of  two  arrow  segments  may  denote  "bundling",  i.e.,  the  combining  of  separate 
meanings  into  a  more  general  category.  All  contents  are  provided  through  all  branches 
unless  otherwise  indicated  by  a  special  label  on  each  arrow  segment.  These  conventions 
are  illustrated  in  Figure  1 1 . 
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Figure  11.  Arrow  Fork  and  Join  Structures 
3. 3. 2. 6  Inter-Box  Connections 

Except  for  the  single-box  A-0  context  diagram,  a  graphic  diagram  contains  a  minimum  of 
three  and  a  maximum  of  six  boxes.  Boxes  are  normally  organized  diagonally  from  the 
upper  left  corner  to  the  lower  right,  i.e.,  in  a  "staircase"  configuration. 

♦ 
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Any  output  arrow  may  provide  some  or  all  of  the  input,  control,  or  mechanism  data  or 
objects  to  any  other  box.  An  output  arrow  may  provide  data  or  objects  to  several  boxes  via 
the  forking  mechanism,  as  shown  in  Figure  12. 


Figure  12.  Connections  Between  Boxes 

If  a  box  on  a  diagram  is  detailed  by  a  child  diagram,  each  arrow  connected  to  the  parent  box 
shall  appear  on  the  child  diagram,  unless  the  arrow  is  tunneled  next  to  its  parent  box  (see 
Section  3. 3. 2. 9). 

On  a  diagram,  data  or  objects  may  be  represented  by  an  internal  arrow,  with  both  ends 
(source  and  use)  connected  to  boxes,  or  by  a  boundary  arrow,  with  only  one  end  (source 
or  use)  connected.  Internal  arrows  and  boundary  arrows  are  shown  in  Figure  13. 
Boundary  arrows  are  discussed  in  detail  in  Sections  3. 3.2. 7  and  3. 3. 2. 8. 


Figure  13.  Boundary  and  Internal  Arrows 


17 


3. 3. 2. 7  Boundary  Arrows 


Boundary  arrows  on  an  ordinary  (non-context)  graphic  diagram  represent  the  inputs, 
controls,  outputs,  or  mechanisms  of  the  diagram's  parent  box.  The  source  or  use  of  these 
boundary  arrows  can  be  found  only  by  examining  the  parent  diagram.  All  boundary 
arrows  on  a  child  diagram  (except  for  tunneled  arrows,  Section  3. 3. 2. 9)  shall  correspond 
to  the  arrows  that  connect  to  its  parent  box,  as  shown  in  Figure  14. 


This  arrow  is  an  input 
on  the  parent  box. 


Figure  14.  Boundary  Arrow  Correspondence 


3.3. 2. 8  ICOM  Coding  of  Boundary  Arrows 

ICOM  codes  relate  boundary  arrows  on  a  child  diagram  to  arrows  connected  to  its  parent 
box.  A  specific  notation,  called  ICOM  codes,  specifies  the  matching  connections.  The 
letter  I,  C,  O  or  M  is  written  near  the  unconnected  end  of  each  boundary  arrow  on  the  child 
diagram.  This  coding  identifies  the  arrow  as  an  Input,  Control,  Output  or  Mechanism  on 
the  parent  box.  This  letter  is  followed  by  a  number  giving  the  relative  position  at  which  the 
arrow  is  shown  connecting  to  the  parent  box,  numbering  from  left  to  right  or  top  to  bottom. 
For  example,  “C3”  written  on  a  boundary  arrow  on  a  child  diagram  indicates  that  this 
arrow  corresponds  to  the  third  control  arrow  (from  the  left)  entering  its  parent  box. 

This  coding  relates  each  child  diagram  to  its  own  immediate  parent  box.  If  boxes  on  a  child 
diagram  are  detailed  on  subsequent  child  diagrams,  new  ICOM  codes  are  assigned  on  each 
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new  child  diagram,  relating  that  diagram's  boundary  arrows  to  arrows  on  its  own 
immediate  parent  box. 

Using  the  letter-numbering  matching  scheme  of  ICOM  coding,  arrow  roles  (input,  control, 
mechanism)  may  differ  between  parent  and  child  diagrams.  Figure  14  shows  the  common 
case  where  the  roles  do  match,  e.g.,  the  input  to  the  parent  box  matches  the  input  on  the 
child  diagram.  As  an  example  of  changing  roles,  a  control  arrow  on  a  parent  box  may  be 
either  an  input  or  a  control  arrow  for  boxes  on  its  child  diagram.  Likewise,  a  control  for  a 
parent  box  may  be  an  input  for  one  or  more  of  its  child  boxes.  Figure  15  shows  examples 
of  changing  arrow  roles. 


CHILD 

DIAGRAM 


NOTE:  The  dashed  lines  show  how  the  ICOMs  on  the  child  diagram  relate  boundary  arrows  on  the 
child  to  the  arrows  of  its  parent  box. 


Figure  15.  ICOM  Codes  and  Changing  Arrow  Roles 
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3. 3. 2. 9  Tunneled  Arrows 


A  tunneled  arrow  is  used  to  provide  information  at  a  specific  level  of  decomposition  that  is 
not  required  for  understanding  at  some  other  levels.  An  arrow  can  be  tunneled  at  any 
chosen  level. 

Using  the  parentheses  notation  illustrated  in  Figure  16,  tunneling  an  arrow  where  it 
connects  to  a  box  side  means  that  the  data  or  objects  expressed  by  that  arrow  are  not 
necessary  for  understanding  subsequent  level(s)  of  decomposition,  and  thus  shall  not  be 
shown  on  its  child  diagram.  However,  because  this  arrow  does  correspond  to  one  on  its 
parent  diagram,  it  is  given  an  ICOM  code.  This  code  may  be  used  elsewhere  in  the  model, 
e.g.,  in  a  reference  expression  on  a  diagram  where  the  arrow  reappears,  in  order  to  identify 
the  location  of  the  original  tunneling.  An  arrow  tunneled  at  its  connected  end  may  be 
omitted  from  one  or  more  levels  of  decomposition  and  then  reappear  on  another  level,  in 
one  or  more  places,  tunneled  at  the  unconnected  end. 


Cl 


II 


m 


►01 


(a) 


These  boundary  arrows  do  not  correspond 
to  arrows  on  the  child  diagram. 


Ml 


Figure  16.  Arrows  Tunneled  at  Connected  End 


Tunneling  an  arrow  at  the  unconnected  end  means  that  the  data  or  objects  are  not  necessary 
at  the  next  higher  (parent)  level  and  hence  shall  not  be  shown  connecting  to  the  parent  box. 
This  is  shown  in  Figure  17.  Because  this  arrow  does  not  correspond  to  one  on  its  parent 
diagram,  it  does  not  have  an  ICOM  code.  The  arrow  may  have  an  attached  model  note 
containing  the  node  reference  and  ICOM  code  that  locates  the  "other  end"  of  the  tunnel. 
ICOM  coding  for  the  arrow  resumes  for  any  subsequent  child  diagrams. 

Figure  18  provides  an  example  of  tunneled  arrows  on  parent  and  child  diagrams. 
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( ) 


These  boundary  arrows  do  not  correspond 
to  arrows  connecting  to  the  parent  box. 


(  ) 


Figure  17.  Arrows  Tunneled  at  Unconnected  End 


the  parent  box. 


Figure  18.  Example  of  Tunneled  Arrows 
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3.3.2.10  Call  Arrows 


A  call  arrow  is  a  special  case  of  mechanism  arrow.  It  signifies  that  the  caller  box  does  not 
have  its  own  child  diagram  to  detail  it,  but  rather  is  detailed  entirely  by  another  box  (and  its 
descendants)  in  the  same  or  another  model.  Multiple  caller  boxes  may  call  the  same  box. 

The  call  arrow  is  labeled  with  the  node  reference  of  the  diagram  containing  the  called  box, 
along  with  the  called-box  number.  A  caller  box  may  call  only  one  box  in  a  given 
activation.  However,  depending  on  conditions  specified  in  a  model  note  attached  to  a  call 
arrow,  the  caller  box  may  select  one  of  several  possible  called  boxes.  In  this  case,  the  call 
arrow  label  shall  include  a  list  of  the  node  references  of  all  the  possible  called  boxes. 

The  arrows  of  the  called  box  may  not  correspond  exactly  with  those  of  the  caller  box,  either 
in  number  or  in  meaning.  In  these  cases,  model  notes  attached  to  the  call  arrows  shall 
specify  the  relationships  so  that  the  correct  interpretation  may  be  given  to  the  shared  data 
and  objects. 

3.3.3  Diagram  Syntax  Rules 

1 .  Context  diagrams  shall  have  node  numbers  A-n,  where  n  is  greater  than  or 
equal  to  zero. 

2.  The  model  shall  contain  a  A-0  context  diagram,  which  contains  only  one 
box. 

3 .  The  box  number  of  the  single  box  on  the  A-0  context  diagram  shall  be  0. 

4.  A  non-context  diagram  shall  have  at  least  three  boxes  and  no  more  than  six 
boxes. 

5 .  Each  box  on  a  non-context  diagram  shall  be  numbered  in  its  lower  right 
inside  comer,  in  order  (from  upper  left  to  lower  right  on  the  diagram  )  from 
1  to  at  most  6. 

6.  Each  box  that  has  been  detailed  shall  have  the  detail  reference  expression 
(DRE,  e.g.,  node  number,  C-number,  or  page  number)  of  its  child  diagram 
written  beneath  the  lower  right  corner  of  the  box. 

7.  Arrows  shall  be  drawn  as  horizontal  and  vertical  straight  line  segments. 
Diagonal  line  segments  shall  not  be  used. 

8.  Each  box  shall  have  a  minimum  of  one  control  arrow  and  one  output  arrow. 

9 .  A  box  shall  have  zero  or  more  input  arrows. 

10.  A  box  shall  have  zero  or  more  non-call  mechanism  arrows. 

11.  A  box  shall  have  0  or  1  call  arrows. 

12.  Control  feedbacks  shall  be  shown  as  “up  and  over”. 
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Input  feedbacks  shall  be  shown  as  “down  and  under”. 


Mechanism  feedbacks  shall  be  shown  as  “down  and  under” 


13.  The  unconnected  end  of  a  boundary  arrow  shall  have  the  proper  ICOM 
code  specifying  its  connection  to  the  parent  box,  or  shall  be  tunneled. 


14.  Open-ended  boundary  arrows  that  represent  the  same  data  or  objects  shall 
be  connected  through  a  fork  to  show  all  the  places  affected,  unless  this 
results  in  an  unreadable  diagram.  Multiple  sources  that  represent  the  same 
data  or  objects  shall  join  to  form  a  single  output  boundary  arrow. 
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15.  Box  names  and  arrow  labels  shall  not  consist  solely  of  the  following  words: 
function,  activity,  process,  input,  output,  control  or  mechanism. 


3.3.4  Diagram  Reference  Expressions 


Reference  expressions  use  codes  that  are  assigned  to  model  features  such  as  diagrams, 
boxes,  arrows  and  notes.  Reference  expressions  then  can  be  used  in  various  contexts  to 
refer  precisely  to  any  aspect  of  the  model. 

The  basic  unit  of  reference  is  the  node  number,  which  applies  to  the  place  where  functional 
decomposition  is  modeled  by  the  detailing  of  a  parent  box  on  a  child  diagram.  All  other 
reference  codes  are  based  on  node  numbers. 


3.3.4. 1  Box  Numbers 

Each  box  on  a  diagram  shall  be  numbered  in  the  lower  inside  right  corner  of  the  box.  This 
numbering  system  is  required  to  uniquely  identify  the  boxes  within  a  diagram,  and  to 
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generate  node  numbers.  It  is  also  used  to  cross-reference  descriptive  entries  in  the  text  and 
glossary  to  the  boxes  on  a  diagram. 

The  box  number  for  the  single  box  on  the  A-0  context  diagram  shall  be  0  (zero).  The  box 
numbers  for  the  boxes  on  all  other  graphic  diagrams  shall  be  1,2,  3,  to  at  most  6,  to 
uniquely  identify  the  three  to  six  boxes  on  each  such  diagram.  For  boxes  arranged 
diagonally  on  the  diagram  from  the  top  left  corner  to  the  bottom  right  comer,  box  numbers 
are  assigned  in  order,  starting  at  the  upper  left.  If  off-diagonal  boxes  are  also  used,  the 
numbering  sequence  starts  with  the  on-diagonal  boxes  and  then  continues,  from  the  lower 
right,  in  counter-clockwise  order. 

3. 3. 4. 2  Node  Numbers 

A  node  number  is  based  on  the  position  of  a  box  in  the  model  hierarchy.  Normally,  a  node 
number  is  formed  by  appending  a  box  number  to  the  node  number  of  the  diagram  on  which 
it  appears.  For  example,  the  node  number  of  box  2  on  diagram  A25  is  A252.  (All  IDEFO 
node  numbers  begin  with  a  capital  letter,  such  as  "A".)  When  a  box  is  detailed  by  a  child 
diagram,  the  node  number  of  the  parent  box  is  assigned  as  the  diagram  node  number;  thus, 
the  parent  box  and  its  child  diagram  have  the  same  node  number. 

Context  diagrams  and  the  top-level  child  diagram  are  exceptions  to  the  above  node¬ 
numbering  scheme.  Every  IDEFO  m^del  has  a  top-level  context  diagram,  the  A-0  diagram. 
This  diagram  contains  a  single  "top  box"  which  is  the  unique  parent  of  the  entire  modeled 
subject  and  bears  the  unique  box  number  0  (zero)  and  node  number  AO.  Every  IDEFO 
model  shall  also  have  at  least  three,  but  no  more  than  six,  child  boxes  on  the  AO  child 
diagram  that  details  the  AO  parent  top  box,  those  boxes  bearing  the  unique  node  numbers 
Al,  A2,  A3,  to  at  most  A6.  Thus,  the  sequence  [AO,  Al,  ...,  A2,  ...,  A3,  ...]  starts  the 
node  numbering  for  each  model. 

For  example,  a  model  might  have  the  following  node  numbers: 


A-l 

A-0 


AO 

Al,  A2,  ...,  A6 

All,  A12,  ....,  A16,  ....,  A61,  ...  ,  A66 
Al  1 1,  Al  12,  ...,  A161,  ....,  A61 1,  ...,  A666 


Optional  higher-level  context  diagrams 
Optional  context  diagram 
Required  top-level  context  diagram 
(contains  AO  top  box) 

Top  level  child  diagram 
Child  diagrams 
Child  diagrams 
Child  diagrams 
Lower-level  child  diagrams 


Node  numbers  may  also  be  used  as  detail  reference  expressions  to  indicate  the  detailing  of  a 
parent  box  by  a  child  diagram.  If  a  function  has  been  decomposed,  the  node  number  of  the 
child  diagram  which  detailed  it  may  be  written  beneath  the  lower  right  corner  of  the  parent 
box.  In  Figure  7,  the  DREs  (in  this  case,  node  numbers)  for  boxes  1,  2  and  3  indicate  that 
they  have  been  detailed  and  identify  the  child  diagrams. 


3. 3. 4. 2.1  Node  Index 


The  node  index  is  a  presentation  of  node  information  in  an  "outline"  format.  All  node 
numbers,  along  with  either  diagram  titles  or  box  names,  shall  be  presented  in  an  indented 
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form  that  exhibits  the  nested  hierarchic  structure  of  the  model.  This  places  related  diagrams 
together  in  the  order  used  in  an  ordinary  Table  of  Contents,  as  is  illustrated  in  Figure  19. 


AO  Manufacture  Product 

A1  Plan  For  Manufacture 

All  Identify  Manufacturing  Methods 
A12  Estimate  Requirements,  Time,  Cost  to  Produce 
A13  Develop  Production  Plans 
A 14  Develop  Support  Activities  Plan 

A2  Make  and  Administer  Schedules  and  Budgets 

A2 1  Develop  Master  Schedule 

A22  Develop  Coordinating  Schedule 

A23  Estimate  Costs  &  Make  Budgets 

A24  Monitor  Performance  To  Schedule  &  Budget 

A3  Plan  Production 


Figure  19.  Typical  Node  Index 


3. 3. 4. 2. 2  Node  Tree 

The  developed  IDEFO  model  with  its  structured  decomposition  provides  the  basis  to  sketch 
the  full  decomposition  in  node  tree  fashion  on  a  single  large  diagram.  The  use  of  a  node 
tree  is  optional.  The  content  of  the  node  tree  shall  be  identical  to  that  of  the  node  index  or 
any  suitable  portion  of  interest. 

There  is  no  standard  format  for  the  actual  display  of  the  node  information,  except  that  the 
hierarchy  shall  be  shown  graphically  as  a  tree  rooted  at  a  chosen  node  (e.g.,  AO  for  the 
whole  model).  Figure  20  provides  an  illustration. 
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PRODUCE 


Figure  20.  Typical  Node  Tree 


3. 3. 4. 3  Node  References 

Each  diagram  in  a  model  has  a  node  reference,  which  uniquely  identifies  it  and  its  position 
in  the  model  hierarchy.  The  node  reference  is  composed  of  the  abbreviated  model  name 
(see  Section  3.4.5)  and  the  diagram  node  number  (see  Section  3. 3. 4. 2),  separated  by  a 
slash  (/).  For  example,  a  model  named  Quality  Assurance  Operations  might  be  abbreviated 
as  QA,  and  a  node  reference  might  then  be  QA/A312.  References  to  a  diagram  in  the  same 
model  may  omit  the  model  name  abbreviation,  using  only  the  diagram  node  number. 

A  node  reference  may  also  have  a  suffix,  e.g.,  F  (for  FEO),  T  (for  text),  or  G  (for 
glossary),  and  a  page  number.  For  example,  a  node  reference  for  a  FEO  might  be 
QA/A321F1  (see  Section  3.4.4). 

3. 3. 4. 4  Model  Notes 

Model  notes  are  optional.  They  are  denoted  by  an  integer  "n"  inside  a  small  square  box 

(El)  For  a  given  diagram,  the  note  numbers  shall  form  a  consecutive  sequence,  starting  at 
1.  Vertical  pipes  surrounding  the  note  number  (  In!  ),  may  be  used  as  an  alternative 
notation. 

Model  notes  provide  information  that  is  relevant  to  (and  an  integral  part  of)  a  diagram's 
message,  but  that  does  not  conveniently  fit  into  the  box-and-arrow  syntax.  If  the  text  of  the 
note  is  to  apply  to  several  places  or  several  features  of  the  diagram,  the  boxed  note  number 
(without  text)  may  be  copied  and  may  be  attached  by  an  IDEFO  squiggle  to  each  point  of 
application,  but  only  on  the  single  diagram  on  which  the  model  note's  text  appears. 
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3. 3. 4. 5  Reference  Notation 


A  standard  notation  is  used  in  writing  text  and  notes  to  refer  to  diagrams  and  specific  parts 
of  diagrams.  References  are  based  on  box  numbers,  node  numbers,  ICOM  codes,  and 
note  numbers.  The  following  table  provides  examples  of  reference  notations. 


REFERENCE  NOTATION 

MEANING 

211 

Box  2  Input  1 

02 

The  boundary  arrow  with  ICOM  code  02 

202  to  3C1  or  2o2  to  3c  1 

The  arrow  from  202  to  3C1  (The  I,  0,  C  or  M 
may  be  upper  case  or  lower  case.) 

12  to  213  to  202  to  (3C1  and  4C2) 

From  the  boundary  arrow  with  ICOM  code  12 
to  Box  2  Input  3,  through  the  activation  of  Box 
2  that  yields  Output  2,  to  the  availability  (via  a 
forking  branch)  of  that  output  as  Control  1  on 
Box  3  and  Control  2  on  Box  4. 

A21.3C2 

On  diagram  A21  in  this  model,  see  Box  3 
Control  2.  An  embedded  period  means  "look 
specifically  at". 

A42.  dl 

On  diagram  A42,  see  model  note  3. 

A42.I3I 

Same  as  above,  using  optional  notation  (vertical 
pipes  surrounding  model  note  instead  of  boxed 
note). 

A42.3 

On  diagram  A42  in  this  model,  see  Box  3. 

MFG/A42.1 

On  diagram  A42  of  the  model  abbreviated 
MFG,  see  Box  1. 
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3.4  Models 


3.4.1  IDEFO  Model  Description 

One  of  the  most  important  features  of  IDEFO  as  a  modeling  concept  is  that  it  gradually 
introduces  greater  and  greater  levels  of  detail  through  the  diagram  structure  comprising  the 
model.  In  this  way,  communication  is  enhanced  by  providing  the  reader  with  a  well- 
bounded  topic  with  a  manageable  amount  of  detail  to  learn  from  each  diagram. 

An  IDEFO  model  starts  by  presenting  the  whole  subject  as  a  single  unit  -  a  box  with 
external-arrow  boundary  conditions  connecting  it  to  functions  and  resources  outside  the 
subject.  The  single  box  is  called  the  "top  box"  of  the  model.  (This  top  box  has  node 
number  AO.)  Since  the  single  top  box  of  an  IDEFO  model  represents  the  subject  as  a 
whole,  the  descriptive  name  in  the  box  is  general.  The  same  is  true  of  the  external  arrows 
of  the  model,  since  they  represent  the  complete  set  of  external  boundary  conditions  of  the 
subject  as  a  whole,  including  access  to  mechanism  support  that  supplies  additional  means 
of  performance. 

3.4.2  Context  Diagrams 

The  diagram  in  which  the  AO  top  box  appears  represents  the  context  of  the  model  and  is 
called  a  context  diagram.  The  minimum  context  for  a  model  is  the  special  context  diagram 
with  the  node  number  A-0.  The  A-0  context  diagram  has  only  the  single  named  AO  top 
box,  with  its  labeled  external  arrows,  and  also  textual  definitions  of  the  Viewpoint  and 
Purpose  of  the  model.  (The  A-0  diagram  has  no  ICOM  codes  or  tunneling  at  unconnected 
arrow  ends.) 

Sometimes,  however,  in  order  to  provide  a  more  complete  exposition  of  the  environmental 
context  of  the  model,  an  optional  A-l  context  diagram  (having  the  appearance  of  an 
ordinary,  non-context,  diagram)  is  also  presented.  In  the  A- 1  context  diagram,  the  AO  box 
takes  the  place  of  one  of  the  three-to-six  numbered  boxes  (the  other  boxes  retaining  their 
expected  box  number),  so  the  effect  is  to  provide  a  complete  parent  diagram  (with  three  to 
six  boxes)  for  the  model's  top  -  the  A1  through  A6  nodes  still  being  the  first-generation 
children.  In  the  case  where  an  A-l  context  diagram  is  used,  an  A-0  context  diagram  is  still 
presented.  This  A-0  diagram  still  has  only  the  single  named  AO  top  box,  with  its  labeled 
external  arrows  and  also  textual  definitions  of  the  Viewpoint  and  Purpose  of  the  model. 

Context  diagrams  are  diagrams  that  have  node  numbers  of  the  form  "A-n"  (with  a  minus 
sign  included),  where  n  is  greater  than  or  equal  to  zero.  Ordinary,  non-context  diagrams 
lack  the  minus  sign  in  their  node  numbers.  The  box  number  of  the  top  box  of  the  model 
(representing  the  whole  of  the  modeled  subject)  always  is  0.  Box  number  0  shall  appear  on 
the  required  A-0  context  diagram  of  the  model,  and  shall  also  appear  on  the  optional  A-l 
context  diagram  (if  any)  where  it  takes  the  place  of  one  of  the  boxes  ( 1  to  at  most  6)  of  that 
A-l  (model-wide)  parent  diagram.  Thus  AO  always  is  the  (shared)  node  number  of  the 
parent  box  and  child  diagram  for  the  whole  model  and  always  is  detailed  by  boxes  with 
node  numbers  Al,  A2,  A3,  to  at  most  A6. 

With  only  one  box,  A-0  is  a  proper  context  diagram  but  is  not  a  (proper)  parent  diagram. 
Proper  diagrams  have  three  to  six  boxes.  The  parental  context  is  that  which  provides  or 
names  the  context  for  a  diagram  in  the  place  of  a  proper  parent  diagram.  The  parental 
context  of  the  AO  diagram  is  the  required  A-0,  if  there  is  no  A-l  context  diagram.  If  there 
is  an  A-l  context  diagram,  A-l  is  the  proper  parent  of  the  AO  diagram.  The  parental 
context  of  the  A-0  context  diagram  always  is  "TOP". 


28 


3.4.3  High-Level  Context  Diagrams 

High-level  context  diagrams  have  node  numbers  of  the  form  A-n,  for  n  greater  than  one. 
Thus  A-l  is  a  context  diagram,  is  a  proper  parent  (of  AO),  but  is  not  high  level.  For  a 
given  model  presentation,  the  highest-level  context  diagram  (largest  n)  has  parental  context 
"NONE",  unless  the  highest-level  context  diagram  is  A-0. 

Each  high-level  context  diagram,  A-n,  syntactically  is  an  ordinary  detail  diagram  except  that 
one  of  its  three-to-six  boxes  has  its  box  number  replaced  by  "minus  sign  n-1",  so  that,  for 
A-l,  that  box  is  the  AO  top  box  of  the  model,  and  the  model  as  a  whole  (that  AO  box  itself, 
the  parent  of  the  children)  appears  to  have  parent  A-l,  grandparent  A-2,  etc. 

By  providing  a  more  complete  description  of  the  model's  environmental  context  (not, 
however,  intended  to  be  definitive  in  all  respects,  but  only  "typical"),  context  modeling 
(characterized  by  negative  node  numbering)  provides  more-constraining  specifications  on 
the  boundary  conditions  of  the  AO  diagram  of  the  model. 

Context  modeling  proceeds  just  as  ordinary  detail  modeling,  the  only  difference  being  the 
negative  numbering  (and  the  non-definitive,  but  normative  interpretation)  that  preserves  AO 
as  the  "origin"  of  the  node-number-based  coordinate  system  for  all  model  references. 

All  the  negative-node-number  modeling  merely  provides  more  and  more  details  about  the 
sources  and  uses  of  the  external  boundary  conditions.  That  detail  may  not  precisely  be 
matched  by  any  particular  specific  environment,  completely.  These  context  diagrams 
describe  the  "typical"  context. 

Figure  21  provides  an  illustration  in  node-tree  form  to  show  how  rich  high-level  context 
might  appear. 
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3.4.4  FEOs,  Text  and  Glossary 


The  node-numbering  scheme  provides  the  basis  for  coordinating  FEOs,  text,  and  glossary 
terms.  During  development  it  is  important  that  each  new  element  of  information  be 
associated  with  the  node  that  brought  it  into  consideration. 

For  each  form  (FEOs,  text,  and  glossary),  the  node-numbering  extension  notation  consists 
of  a  single  letter  appended  to  the  associated  node  number.  For  example,  node  numbers  for 
FEOs  shall  contain  an  “F”  for  FEO  (e.g.,  A312F). 

Some  IDEFO  users  record  glossary  definitions  on  IDEFO  diagram  forms,  though  the  use  of 
this  form  for  glossaries  is  not  required.  In  this  case,  a  glossary  page  shall  define  the  key 
words,  phrases  and  acronyms  used  with  a  particular,  associated  IDEFO  node.  The  node 
numbers  for  such  glossary  pages  shall  contain  a  "G"  for  glossary  (e.g.,  A312G). 

Likewise,  some  IDEFO  users  record  their  textual  comments  on  IDEFO  diagram  forms, 
though  the  use  of  this  form  for  text  is  not  required.  In  this  case,  a  text  page  shall  provide 
the  text  comments  for  a  particular,  associated  IDEFO  node.  The  node  numbers  for  such 
text  pages  shall  contain  a  "T"  for  text  (e.g.,  A312T). 

If  there  is  more  than  one  FEO,  glossary  or  text  page  associated  with  a  given  IDEFO  node, 
the  pages  should  be  designated  with  an  additional  number  to  uniquely  identify  each  (e.g., 
A312F1,  A312F2,...A312G1,  A312G2,...,  A312T1,  A312T2,  ...). 

3.4.5  Model  Name 

Each  model  has  a  unique,  descriptive  name  that  distinguishes  it  from  other  models  with 
which  it  may  be  associated.  This  model  name  is  normally  abbreviated  (uniquely)  for  use  in 
node  references.  For  example,  a  model  named  Manufacturing  Operations  may  be 
abbreviated  MFG.  See  Section  3. 3.4. 3  for  a  discussion  of  node  references. 

3.4.6  Presentation  Rules 

1 .  When  there  is  text,  it  shall  accompany  the  associated  graphic  diagram. 

2.  In  non-publication  models,  the  glossary  associated  with  a  specific  graphic 
diagram  shall  accompany  the  diagram  and  shall  define  only  the  key  words, 
phrases  and  acronyms  used  with  the  particular  node. 

3.  In  publication  models,  a  glossary  section  shall  define  the  key  words, 
phrases  and  acronyms  in  alphabetical  order  for  the  entire  model. 

4.  When  a  table  of  contents  is  provided  for  a  model,  it  shall  be  presented  as  a 
node  tree  or  node  index,  and  shall  contain  node  numbers,  diagram  titles  and 
box  names. 
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ANNEX  A  -  IDEFO  CONCEPTS 


A.l  Background 

The  desire  of  the  U.S.  Air  Force  to  reduce  costs  and  lead  times  by  assisting  the  aerospace 
industry  in  its  modernization  efforts  is  evidenced  in  its  many  “Tech  Mod”  (Technology 
Modernization)  programs.  A  similar  goal,  but  using  an  industry-wide  target  rather  than 
individual  companies,  was  established  under  the  ICAM  (Integrated  Computer  Aided 
Manufacturing)  Program.  In  ICAM,  the  goal  was  to  develop  “generic  subsystems”  which 
could  be  used  by  a  large  number  of  companies  to  provide  a  significant  upgrade  to  the 
industry  as  a  whole.  These  “subsystems”  provide  support  for  common  functions  such  as 
management  of  information,  shop  floor  scheduling  and  materials  handling. 

This  ambitious  goal  needed  a  common  “baseline”  communication  vehicle  around  which  to 
plan,  develop  and  implement  the  subsystems  in  the  individual  aerospace  companies.  The 
baseline  was  called  the  “Architecture  of  Manufacturing”,  since  it  was  to  provide  an 
industry-wide  “architecture”  showing  how  industry  works  today  and  around  which  generic 
subsystems  could  be  planned,  developed  and  implemented. 

To  develop  the  architecture,  a  “language”  was  needed  in  which  to  express  and  document 
current  aerospace  industry  operations.  At  the  outset  of  ICAM,  the  Air  Force  issued  a 
Request  for  Proposal  to  build  the  architecture.  An  activity  modeling  technique  was 
specified  as  the  expressive  language  (where  an  activity  was  defined  as  a  manufacturing  cell 
or  operational  unit).  To  be  successful,  the  language  had  to  satisfy  the  following  criteria: 

•  Since  the  architecture  was  to  depict  manufacturing,  it  had  to  be  able  to 
express  manufacturing  operations  in  a  natural  and  straightforward  way. 

•  Since  the  subject  was  so  vast  and  complex,  it  had  to  be  concise  and  provide 
a  straightforward  means  of  locating  details  of  interest  easily  and  quickly. 

•  Since  it  was  to  be  used  by  a  wide  audience,  it  had  to  be  able  to  communicate 
to  a  wide  variety  of  aerospace  industry  personnel  as  well  as  to  Air  Force 
ICAM  Program  Office  personnel. 

•  Since  it  was  to  serve  as  a  baseline  for  generic  subsystem  planning, 
development  and  implementation,  it  had  to  permit  sufficient  rigor  and 
precision  to  insure  orderly  and  correct  results. 

•  Since  the  baseline  was  to  be  developed  through  the  cooperative  effort  of  a 
large  segment  of  the  aerospace  industry,  it  had  to  include  a  methodology 
(rules  and  procedures)  for  its  use  that  would  permit  many  diverse  groups  to 
develop  architecture  pieces  and  that  would  permit  wide-spread  review, 
critique  and  approval. 

•  Since  the  baseline  was  to  represent  the  entire  aerospace  industry  rather  than 
any  one  company  or  industry  segment,  the  technique  had  to  include  a  means 
of  separating  “organization”  from  “function”;  that  is,  a  common  agreement 
could  not  be  achieved  unless  the  individual  companies’  organizational 
differences  were  separated  out  and  only  the  common  functional  thread  was 
captured. 

The  SADT™  (Structured  Analysis  and  Design  Technique™)  originally  developed  in  1972 
by  Douglas  T.  Ross,  of  SofTech,  was  selected  as  the  “The  Architecture  Method”  for  use  in 
the  Air  Force  Computer  Aided  Manufacturing  (AFCAM)  Project.  The  activity  modeling 
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technique  was  further  developed  and  used  in  the  follow-on  ICAM  Part  I  Program.  The 
major  subset  of  this  technique  used  by  the  ICAM  Part  II  Program  Office  was  later  re-named 
and  documented  as  “IDEFO”. 

A. 2  IDEFO  Concepts 

The  original  IDEFO  methodology  incorporated  basic  concepts  which  address  each  of  the 
needs  listed  above.  These  basic  IDEFO  concepts  are: 

1 .  Activity  Modeling  Graphic  Representation.  The  “box  and  arrow”  graphics  of  an 
IDEFO  diagram  show  the  manufacturing  operation  as  the  box,  and  the  interfaces 
to/from  the  operation  as  the  arrows  entering/leaving  the  box.  In  order  to  be  able  to 
express  real-life  manufacturing  operations,  boxes  may  be  interpreted  as  operating 
with  other  boxes,  with  the  interface  arrows  providing  “constraints”  as  to  when  and 
how  operations  are  triggered  and  controlled. 

2.  Conciseness.  The  documentation  of  a  manufacturing  architecture  must  be  concise 
to  permit  encompassing  the  subject  matter.  The  linear,  verbose  characteristic  of 
ordinary  language  text  is  clearly  insufficient.  The  two-dimensional  form  provided 
by  a  blueprint-like  language  has  the  desired  conciseness  without  losing  the  ability  to 
express  relationships  such  as  interfaces,  feedback  and  error  paths. 

3 .  Communication.  There  are  several  IDEFO  concepts  which  are  designed  to  enhance 
communications: 

•  Diagrams  based  upon  very  simple  box  and  arrow  graphics. 

•  English  text  to  specify  box  (function)  and  arrow  (data  or  objects)  meanings. 

•  Gradual  exposition  of  detail,  featuring  a  hierarchy  with  major  functions  at  the 

top  and  successive  levels  of  sub-functions  revealing  well-bounded  detail 
breakout. 

•  A  node  index  for  locating  details  within  the  hierarchic  structure  of  diagrams. 

•  Limitation  of  detail  on  each  successive  diagram  to  not  more  than  six 

sub-functions  for  ease  of  reader  comprehension. 

•  Diagrams  supported  with  text  and  glossary  to  increase  the  preciseness  of  the 

graphic  representation. 

4.  Rigor  and  Precision.  The  rules  of  IDEFO  enforce  sufficient  rigor  and  precision  to 
satisfy  ICAM  architecture  needs  without  overly  constraining  the  analyst.  IDEFO 
rules  include: 

•  Detail  exposition  control  at  each  level  (3-6  box  rule). 

•  Bounded  context  (no  omissions  or  additional  out-of-scope  detail). 

•  Syntax  rules  for  graphics  (boxes  and  arrows). 

•  Uniqueness  of  names  and  labels  on  a  diagram. 

•  Diagram  connectivity  (Detail  Reference  Expressions  [DRE]). 

•  Data/object  connectivity  (ICOM  codes  and  tunneled  arrows). 

•  Input  vs.  control  separation  (rule  for  determining  role  of  data  or  objects). 

•  Minimum  control  of  function  (all  functions  require  at  least  one  control). 

•  Arrow  branch  (fork  or  join)  constraint  (labels  for  arrow  segments). 

•  Arrow  label  requirements  (minimum  labeling  rules). 

•  Purpose  and  viewpoint  (all  models  shall  have  a  purpose  and  viewpoint 

statement). 

5.  Methodology.  Step-by-step  procedures  are  provided  for  modeling,  review  and 
interview  tasks. 
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6.  Organization  vs.  Function.  The  separation  of  organization  from  function  is 
included  in  the  purpose  of  the  model  and  carried  out  by  the  selection  of  functions 
and  arrow  labels  during  model  development.  Continual  review  during  model 
development  ensures  that  organizational  viewpoints  are  avoided. 

A.3  Discussion  of  Individual  IDEFO  Concepts 

In  the  remaining  sub-sections  descriptions  of  some  of  the  basic  concepts  are  elaborated  to 
clarify  them  and  show  their  utility. 

A.3.1  Activity  Modeling  Graphics 

The  IDEFO  methodology  may  be  used  to  model  a  wide  variety  of  automated  and  non- 
automated  “systems”  or  subject  areas,  including  any  combination  of  hardware,  software, 
machines,  processes  or  people.  For  new  systems  IDEFO  may  be  used  first  to  define  the 
requirements  and  specify  the  functions,  and  then  to  design  an  implementation  that  meets  the 
requirements  and  performs  the  functions.  For  existing  systems,  IDEFO  can  be  used  to 
analyze  the  functions  the  system  performs  and  to  record  the  mechanisms  (means)  by  which 
these  are  done. 

The  result  of  applying  IDEFO  is  a  model.  A  model  consists  of  diagrams,  text  and  glossary, 
cross-referenced  to  each  other.  Diagrams  are  the  major  components  of  a  model.  All 
functions  and  interfaces  are  represented  as  boxes  (functions)  and  arrows  (data  or  object 
interfaces)  on  diagrams. 

The  position  at  which  the  arrow  attaches  to  a  box  conveys  the  specific  role  of  the  interface. 
The  controls  enter  the  top  of  the  box.  The  inputs,  the  data  or  objects  acted  upon  by  the 
operation,  enter  the  box  from  the  left.  The  outputs  of  the  operation  leave  the  right-hand 
side  of  the  box.  Mechanism  arrows  that  provide  supporting  means  for  performing  the 
function  join  (point  up  to)  the  bottom  of  the  box.  Call  arrows,  a  type  of  mechanism  arrow 
which  enables  the  sharing  of  detail  between  models  or  between  portions  of  the  same  model, 
connect  to  the  bottom  of  the  box  and  point  downward.  These  arrow  positions  are 
illustrated  in  Figure  A 1 . 
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Figure  Al.  Function  Box  and  Data/Objects  Arrows 
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These  box  and  arrow  meanings  are  used  to  relate  several  sub-functions  on  a  diagram 
comprising  a  more  general  function.  This  diagram  is  a  “constraint  diagram”  which  shows 
the  specific  interfaces  which  constrain  each  sub-function,  as  well  as  the  sources  and  targets 
of  the  interface  constraints  (Figure  A2). 


Figure  A2.  Constraint  Diagrams 


In  Figure  A2,  Function  B  is  constrained  by  one  input  and  two  controls,  and  produces  a 
single  output,  which  constrains  Function  C. 

Here,  the  term  “constrains”  means  that  a  function  uses  the  data  or  objects  shown  entering 
the  box,  and  therefore,  is  constrained  from  operating  by  the  interface;  the  function  cannot 
act  until  the  contents  of  the  interface  arrow  are  provided,  and  the  way  in  which  the  function 
operates  depends  upon  the  details  (value,  number,  etc.)  of  the  contents  of  the  interface 
arrow. 

A.3.2  Communication  by  Gradual  Exposition  of  Detail 

One  of  the  most  important  features  of  IDEFO  is  that  it  gradually  introduces  greater  and 
greater  levels  of  detail  through  the  diagram  structure  comprising  the  model.  In  this  way, 
communication  is  enhanced  by  providing  the  reader  with  a  well-bounded  topic  with  a 
manageable  amount  of  new  information  to  learn  from  each  diagram. 

The  structure  of  an  IDEFO  model  is  shown  in  Figure  A3.  Here,  a  series  of  four  diagrams 
is  shown  with  each  diagram's  relation  to  the  others. 

An  IDEFO  model  starts  by  representing  the  whole  system  as  a  single  unit  -  a  box  with 
arrow  interfaces  to  functions  outside  the  system.  Since  the  single  box  represents  the 
system  or  subject  area  as  a  whole,  the  descriptive  name  written  in  the  box  is  general.  The 
same  is  true  of  the  interface  arrows  since  they  also  represent  the  complete  set  of  external 
interfaces  to  the  system  as  a  whole.  The  diagram  with  the  single  box  is  called  the  “context 
diagram,”  and  shall  define  in  text  the  viewpoint  and  purpose  of  the  model. 
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The  box  that  represents  the  system  as  a  single  module  is  then  detailed  on  another  diagram 
with  boxes  connected  by  interface  arrows.  These  boxes  represent  major  sub-functions  of 
the  single  parent  function.  This  decomposition  reveals  a  complete  set  of  sub-functions, 
each  represented  as  a  box  whose  boundaries  are  defined  by  the  interface  arrows.  Each  of 
these  sub-functions  may  be  similarly  decomposed  to  expose  even  more  detail.  In  IDEFO, 
we  use  the  following  terminology:  functions  are  “decomposed”;  the  boxes  that  represent 
functions  are  “detailed”. 

A  box,  if  detailed,  is  always  detailed  on  a  child  diagram  into  no  fewer  than  three  boxes,  but 
no  more  than  six  boxes.  The  upper  limit  of  six  forces  the  use  of  a  hierarchy  to  describe 
complex  subjects.  The  lower  limit  of  three  insures  that  enough  detail  is  introduced  to  make 
the  decomposition  (detailing)  of  interest. 

Each  diagram  in  a  model  is  shown  in  precise  relationship  to  other  diagrams  by  means  of 
interconnecting  arrows.  When  a  function  is  decomposed  into  sub-functions,  the  interfaces 
between  the  sub-functions  are  shown  as  arrows.  The  name  of  each  sub-function  box  plus 
its  labeled  interfaces  define  a  bounded  context  for  that  sub-function. 

In  all  cases,  every  sub-function  is  restricted  to  contain  only  those  elements  that  lie  within 
the  scope  of  its  parent  function.  Sub-functions  are  discrete  and  do  not  overlap.  Further, 
the  collection  of  sub-functions  cannot  omit  any  elements.  Thus,  as  already  indicated,  the 
parent  box  and  its  interfaces  provide  a  context  for  its  child  diagram.  Except  for  tunneled 
arrows,  nothing  may  be  added  or  removed  from  this  precise  boundary. 

A. 3. 3  Disciplined  Teamwork 

The  IDEFO  methodology  includes  procedures  for  developing  and  critiquing  models  by  a 
large  group  of  people,  as  well  as  integrating  support  subsystems  into  an  IDEFO 
Architecture.  Additional  supporting  procedures,  such  as  librarian  rules  and  procedures, 
and  review  cycle  (see  Annex  C)  procedures  are  also  included  in  the  IDEFO  methodology. 
(It  should  be  noted  that  some  of  these  rules  and  procedures,  such  as  the  Kit  Cycle  or 
Reader-Author  Cycle  critique  procedures,  are  also  used  with  other  IDEF  techniques.) 

The  creation  of  an  IDEFO  model  is  the  most  basic  of  these  “disciplined  teamwork” 
procedures.  The  creation  of  a  model  is  a  dynamic  process  which  usually  requires  the 
participation  of  more  than  one  person.  Throughout  a  project,  authors  create  initial  diagrams 
which  are  distributed  to  project  members  for  review  and  comment.  The  discipline  requires 
that  each  person  expected  to  make  comments  about  a  diagram  shall  make  them  in  writing 
and  submit  them  to  the  author  of  the  diagram.  The  author  replies,  also  in  writing.  This 
cycle  continues  until  the  diagrams,  and  eventually  the  entire  model,  are  officially  accepted. 

IDEF  includes  procedures  for  retaining  written  records  of  all  decisions  and  alternate 
approaches  as  they  unfold  during  the  project.  Copies  of  the  diagrams  created  by  an  author 
are  critiqued  by  knowledgeable  readers  who  document  suggestions  directly  onto  the  copies. 
Authors  respond  to  each  comment  in  writing  on  the  same  copy.  Suggestions  are  accepted 
or  rejected  in  writing  along  with  the  reasoning  used.  As  changes  and  corrections  are  made, 
outdated  versions  of  diagrams  are  retained  in  the  project  files. 

The  diagrams  are  changed  to  reflect  corrections  and  comments.  More  detail  is  added  to  the 
model  by  the  creation  of  more  diagrams  which  also  are  reviewed  and  changed.  The  final 
model  represents  an  agreement  on  a  representation  of  the  system  or  subject  area  from  a 
given  viewpoint  and  for  a  given  purpose.  This  representation  can  be  easily  read  by  others 
outside  the  initial  project,  used  for  presenting  the  system  definition  in  short  stand-up 
briefings  or  in  walk-throughs,  and  for  organizing  new  projects  to  work  on  system  changes. 
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ANNEX  B  -  CREATING  AND  INTERPRETING  IDEFO 
DIAGRAMS 


B.l  Reading  IDEFO  Diagrams 

A  model  is  made  up  of  a  collection  of  diagrams  and  associated  materials  arranged  in  a 
hierarchic  manner.  A  node  index  (or  table  of  contents)  shall  be  provided.  Placing  the 
diagrams  in  hierarchical  order  gives  an  overall  view  of  the  model  and  allows  access  to  any 
portion. 

Reading  is  done  top-down,  considering  each  diagram  as  a  context  bounded  by  its  parent 
box.  After  the  top  level  diagrams  are  read,  first  level  diagrams  are  read,  then  second  level 
diagrams  are  read,  etc.  If  specific  details  about  a  model  are  needed,  the  node  index  is  used 
to  descend  through  the  levels  to  the  required  diagram. 

When  published,  a  model  is  bound  in  “page-pair”  format  and  “node  index”  order. 
“Page-pair”  format  means  that  each  diagram  and  the  entire  text  associated  with  it  appear  on 
a  pair  of  facing  pages.  (Figure  B 1 .) 


This  smaller 
diagram  is  the 
parent  for  the 
current  diagram. 


Figure  Bl.  Page-Pair  Format 


“Node  index”  order  means  that  all  child  diagrams  relating  to  one  box  on  a  diagram  are 
presented  before  the  children  of  the  next  box.  This  places  related  diagrams  together  in  the 
same  order  used  in  an  ordinary  table  of  contents.  (Figure  B2.) 
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AO  Plan  for  Manufacture 

A1  Assume  a  Structure  and  Method  of  Mfg. 

A2  Estimate  Requirements,  Cost,  Time  to  Produce 

Order  of 

A2 1  Estimate  Resource  Needs 

diagrams  in 

A22  Estimate  Costs  to  Purchase  or  Make 

a  document 

A23  Estimate  Timing  for  Startup  and  Production 

A3  Develop  Production  Plans 

A4  Develop  Support  Activities  Plan  } 

Figure  B2.  Node  Index  Showing  Diagram  Order 


B.1.1  Approaching  a  Model 

Models  provide  an  overview  of  the  whole  system  or  subject  area  as  well  as  details  of  a 
particular  subject.  To  read  a  model  for  its  overview,  use  the  index  to  find  all  high-level 
diagrams.  (Figure  B3.) 


AO  Manufacture  Product 
A1  Plan  for  Manufacture 

A1 1  Assume  a  Structure  &  Method  of  Mfg. 

A 12  Estimate  Requirements,  Time,  Cost  to  Produce 
A 13  Develop  Production  Plans 
A 14  Develop  Support  Activities  Plan 
A2  Make  &  Administer  Schedules  &  Budgets 
A21  Develop  Master  Schedule 
A22  Develop  Coordinating  Schedule 
A23  Estimate  Costs  &  Make  Budget 
A24  Monitor  Performance  to  Schedule  &  Budget 
A3  Plan  Production 


Figure  B3.  Node  Index  Showing  Overview  Diagrams 


To  read  a  model  for  detail,  use  the  index  to  find  all  diagrams  detailing  the  subject  of 
interest.  (Figure  B4.) 
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AO  Manufacture  Product 
A 1  Plan  for  Manufacture 
A1 1  Assume  a  Structure  &  Method  of  Mfg. 

A 12  Estimate  Requirements,  Time,  Cost  to  Produce 
A13  Develop  Production  Plans 
A14  Develop  Support  Activities  Plan 
A2  Make  &  Administer  Schedules  &  Budgets 
A21  Develop  Master  Schedule 
A22  Develop  Coordinating  Schedule 
A23  Estimate  Costs  &  Make  Budget 
A24  Monitor  Performance  to  Schedule  &  Budget 
A3  Plan  Production 


Figure  B4.  Node  Index  Showing  Specific  Detailed  Diagram 


Further  detailing  in  a  model  may  be  traced  by  referring  to  the  detail  reference  expression 
(DRE)  just  below  the  box  number.  This  indicates  the  node  number,  C-number  or  page 
number  of  the  child  diagram  that  details  the  box.  In  the  example  below,  details  for  box  3 
on  diagram  A24  may  be  found  on  a  diagram  with  node  number  A243.  If  no  DRE  appears, 
the  box  has  not  yet  been  detailed. 


_ 3_ 

A243 

Details  may  be  shared  within  a  model  or  between  different  models.  In  both  cases,  a  call 
arrow  (downward  pointing)  indicates  where  the  shared  detailing  appears  via  a  reference 
expression  that  may  include  a  unique,  abbreviated  model  mane.  In  the  example  below,  box 
4  is  detailed  by  diagram  A4  in  model  MQ.  In  this  example,  the  reference  expression  is  a 
diagram  node  reference. 


_ 4_ 

MQ/A4 

v 


B.1.2  Diagram  Reading  Steps 

The  precise  information  about  a  system  is  in  the  diagrams  themselves.  The  following 
reading  sequence  is  recommended: 

1  Scan  the  boxes  of  the  diagram  to  gain  an  impression  of  what  is  being 
described. 
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2.  Refer  back  to  the  parent  diagram  and  note  the  arrow  connections  to  the 
parent  box.  Try  to  identify  a  “most  important”  input,  control  and  output. 

3 .  Consider  the  arrows  of  the  current  diagram.  Try  to  determine  if  there  is  a 
main  path  linking  the  “most  important”  input  or  control  and  the  "most 
important"  output. 

4 .  Mentally  walk  through  the  diagram,  from  upper  left  to  lower  right,  using  the 
main  path  as  a  guide.  Note  how  other  arrows  interact  with  each  box. 
Determine  if  there  are  secondary  paths.  Check  the  story  being  told  by  the 
diagram  by  considering  how  familiar  situations  are  handled. 

5 .  Check  to  see  if  a  related  FEO  diagram  exists. 

6.  Finally,  read  the  text  and  glossary,  if  provided. 

This  sequence  ensures  that  the  major  features  of  each  diagram  receive  attention.  The  text 
will  call  attention  to  anything  that  the  author  wishes  to  emphasize.  The  glossary  will  define 
the  author's  interpretation  of  the  terminology  used. 

Each  diagram  has  a  central  theme,  running  from  the  most  important  incoming  boundary 
arrow  to  the  most  important  outgoing  boundary  arrow.  This  main  path  through  the  boxes 
and  arrows  outlines  the  primary  function  of  the  diagram.  (Figure  B5.)  Other  parts  of  the 
diagram  represent  qualifying  or  alternative  conditions  which  are  secondary  to  the  main 
path. 
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Figure  B5.  Example  of  Main  Path 
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The  system’s  operation  can  be  mentally  envisioned  by  pursuing  the  main  path.  Specific 
kinds  of  data  inputs,  the  handling  of  errors  and  possible  alternative  outputs  lend  detail  to 
the  story.  This  walk-through  enhances  understanding  of  the  diagrams. 

B.1.3  Semantics  of  Boxes  and  Arrows 

The  fundamental  notion  which  must  guide  the  interpretation  of  any  diagram  or  set  of 
diagrams  is:  Only  that  which  is  explicitly  stated  is  necessarily  implied.  This  derives  from 
the  very  nature  of  constraint  diagrams.  Unspecified  constraints  must  not  be  assumed; 
necessary  constraints  must  be  explicit.  The  corollary  is  that:  Any  further  detailing  not 
explicitly  prohibited  is  implicitly  allowed. 


Tolerance 

\S 


Monitor 

temperature 


Danger  signal 


Figure  B6.  Example  of  Constraint 


An  assumption  can  be  made  using  Figure  B6  that  the  temperature  is  measured  “often 
enough”  and  the  tolerances  are  changed  “when  appropriate”  and  the  temperature  is 
monitored  against  the  tolerances  “often  enough”  that  the  danger  signal  will  be  produced 
“soon  enough”.  None  of  these  intuitive  understandings  would  conflict  with  subsequent 
detailing  which  showed  that: 

a.  the  temperature  was  measured  by  periodic  sampling,  or 

b .  current  tolerances  were  requested  only  when  the  temperature  increased  by 
some  fixed  amount,  or 

c.  a  series  of  temperature  values  produced  by  box  1  was  stored  by  box  2 
which  examined  the  pattern  of  change  to  determine  if  the  pattern  was  within 
the  tolerances,  etc. 

The  graphic  notations  of  a  diagram  are,  by  themselves,  abstract.  However,  they  do  make 
important  fundamental  distinctions.  Their  abstract  nature  should  not  detract  from  the 
intended  breadth  of  possible  interpretations  that  are  permitted. 

B.  1.3.1  Constraints  Omit  How  and  When 

Either  of  the  two  representations: 
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says  that:  the  activity  a2  is  dependent  on  “d”  which  is  created  or  modified  by  the  activity 
al. 

Each  representation  defines  a  constraint  relationship  between  the  two  boxes.  All  that  is 
explicitly  stated  by  the  intermediate  arrow  for  either  representation  is  expressed  as  follows: 
some  activation  of  box  2  requires  something  called  “d”  that  is  produced  by  some  activation 
of  box  1. 

Frequently,  diagrams  imply  strongly  that  two  or  more  boxes  may  need  the  contents  of  an 
arrow.  The  meaning  of  the  boxes  and  arrows  shown  in  Figure  B7  is  that  something 
produced  by  box  1  is  needed  by  box  2  and  by  box  3.  It  may  be  that  an  activation  of  the 
arrow’s  “source”  (box  1)  must  precede  every  activation  of  its  “destination”  (box  2  or  box 
3).  It  may  be  that  one  activation  of  the  source  is  sufficient  for  every  activation  of  any 
destination.  Without  additional  information,  the  boxes  and  arrows  alone  permit  either 
interpretation. 


Figure  B7.  Two  boxes  using  the  contents  of  the  same  arrow 


B. 1.3.2  Multiple  Inputs,  Controls  and  Outputs 

The  basic  interpretation  of  the  box  shown  below  (Figure  B8)  is:  In  order  to  produce  any 
subset  of  the  outputs  [01,  02,  03],  any  subset  of  the  entries  [II,  12,  13,  Cl,  C2,  C3,  C4, 
Ml,  M2,  M3]  may  be  required.  In  the  absence  of  further  detailing  it  cannot  be  assumed 
that: 

a.  any  output  can  be  produced  without  all  entries  present,  or 

b.  any  output  requires  all  entries  for  its  production. 
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Figure  B8.  Illustration  of  ICOM  coding 


The  partial  detailing  of  the  previous  box  (shown  in  Figure  B9,  as  it  might  appear  in  a  FEO 
diagram)  indicates  that  13,  C2,  C3  and  C4  are  not  required  for  producing  01.  Figure  B9 
illustrates  the  points  that: 

a.  some  form  of  further  detailing  will  specify  the  exact  relationship  of  inputs 
and  controls  to  outputs; 

b.  until  that  detailing  is  provided,  limiting  assumptions  about  relationships 
“inside”  each  box  should  not  be  made; 

c.  reading  of  a  diagram  should  concentrate  on  the  arrows,  which  are  explicit, 
rather  than  on  box  names,  which  are  only  implicit. 
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Figure  B9.  FEO  representing  detailing  of  multiple  ICOMs 


B.2  Author's  Guide  to  Creating  IDEFO  Diagrams 

When  creating  any  IDEFO  diagram,  the  requirements  to  be  satisfied  are  that: 

a.  its  purpose  and  viewpoint  shall  match  the  stated  purpose  and  viewpoint  of 
the  overall  model; 

b .  its  boundary  arrows  shall  correspond  to  the  arrows  that  connect  to  its  parent 
box; 

c.  its  content  shall  be  exactly  everything  in  its  parent  box. 

B.2.1  Basic  Steps  of  Authoring 

The  step-by-step  discipline  of  authoring  makes  it  possible  to  create  diagrams  that  form 

useful  and  coherent  models.  The  discipline  to  follow  is: 

a.  Bound  the  subject  matter  more  precisely  than  the  name  of  the  function  box 
suggests.  This  is  done  with  a  list  of  data  and  objects  acted  on  or  processed 
by  the  function. 

b.  Study  the  bounded  set  of  subject  matter  and  form  possible  sub-functions  of 
the  total  function. 

c.  Look  for  natural  patterns  of  connection  of  those  sub-functions. 

d.  Split  and  cluster  sub-functions  to  make  suitable  boxes. 

e.  Draw  a  final  version  of  the  diagram  with  careful  attention  to  layout  and 
clarity. 
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B.2.1.1  Selecting  a  Context,  Viewpoint  and  Purpose 

Before  beginning  any  model,  it  is  important  to  determine  the  model’s  orientation.  This 
includes  the  context,  viewpoint  and  purpose.  These  concepts  guide  and  constrain  the 
creation  of  a  model.  While  they  may  be  refined  as  authoring  proceeds,  they  must  be 
consistent  throughout  a  model  if  its  orientation  is  to  remain  clear  and  undistorted. 

The  context  establishes  the  subject  of  the  model  as  part  of  a  larger  whole.  It  creates  a 
boundary  with  the  environment  by  describing  external  interfaces.  The  context  diagram 
establishes  the  context  for  the  model. 

The  viewpoint  determines  what  can  be  “seen”  within  the  context,  and  from  what  “slant”  or 
perspective.  Depending  on  the  purpose,  different  viewpoints  may  be  adopted  that 
emphasize  different  aspects  of  the  subject.  There  is  only  one  viewpoint  per  model. 

The  purpose  establishes  the  intent  of  the  model  or  the  goal  of  communication  that  it  serves. 
Purpose  embodies  the  reason  why  the  model  is  created  (functional  specification, 
implementation  design,  customer  operations,  etc.). 

The  starting  point  for  every  analysis  is  to  bound  the  context.  Decide  what  the  focus  is 
before  the  top-most  box  is  created.  Beware  of  drifting  out  of  this  carefully-selected  starting 
domain.  Every  step  should  be  checked  against  the  starting  purpose.  Things  that  don’t  fit 
may  be  noted  for  later  modeling  of  the  relevant  views.  Clarity  is  derived  from  the  rigors  of 
detailing.  Knowing  how  far  to  go,  when  to  stop,  when  to  change  gears  and  how  the  pieces 
fit  together  will  always  depend  on  the  purpose  for  which  a  model  is  created. 

B.2.1.2  Creating  the  Context  Diagram 

To  start  a  model,  create  the  A-0  diagram.  Draw  a  single  box  containing  the  name  of  the 
function  which  encompasses  the  entire  scope  of  the  system  being  described.  Use  input, 
control  and  output  arrows  entering  and  leaving  the  box  to  represent  the  data  and  object 
interfaces  of  the  system  to  its  environment.  This  single-box  diagram  bounds  the  context 
for  the  entire  model  and  forms  the  basis  for  further  decomposition  efforts.  State  the 
purpose  and  viewpoint  on  A-0  context  diagram. 

Some  authors  find  it  easier  to  sketch  the  AO  and  then  draw  the  single  box  and  interface 
arrows  shown  at  level  A-0.  It  may  be  necessary  to  switch  diagramming  efforts  back  and 
forth  between  A-0  and  AO  several  times  to  obtain  a  good  start  for  the  decomposition. 

If  the  A-0  diagram  has  begun  at  too  low  a  level  of  detail,  make  the  A-0  box  the  basis  of  a 
new  level  AO  diagram.  Move  up  one  level  to  a  new  A-0  and  revisit  the  Viewpoint  and 
Purpose  statements.  Repeat  this  process  until  an  A-0  is  reached  which  has  sufficient  scope 
to  cover  all  aspects  of  the  system.  (Sometimes  such  a  higher  level  will  broaden  rather  than 
clarify  the  chosen  viewpoint.  If  so,  make  an  A- 1  multi-box  context  diagram  and  keep  the 
AO  diagram  to  the  original  intent.) 

B. 2.1.3  Creating  the  Top-Most  Diagram 

All  system  functions  lie  within  the  single  box  shown  on  the  A-0  diagram.  The  diagram 
bounds  the  context  of  the  system.  The  AO  diagram  decomposes  the  single  function  on  the 
A-0  diagram  into  its  three  to  six  major  sub-functions. 

The  real  “top”  of  the  model  is  the  AO  diagram.  Its  structure  clearly  shows  what  the  A-0 
diagram  tried  to  say.  The  terms  and  structure  of  AO  also  bound  every  subsequent  level 
because  it  is  a  complete  description  of  the  chosen  subject.  Lower  levels  delineate  the  AO 
functions  (boxes).  If  the  purpose  of  the  model  is  to  be  achieved,  this  chain  of  detailing 
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must  be  carefully  followed  at  each  step.  Beginning  at  the  top  is  the  challenge  of  authoring. 
It  forces  the  author  to  maintain  a  level  of  abstraction,  keep  an  even  model  depth  and  relegate 
details  to  a  lower  level. 

B. 2.1.4  Creating  Child  Diagrams 

To  form  the  structure  of  diagrams,  detail  each  box  on  the  AO  diagram  into  its  three  to  six 
major  parts.  Form  a  new  diagram  for  each  box,  which  covers  the  same  topic  as  its  parent 
box  but  in  more  detail. 

To  detail  each  box  by  3  to  6  child  boxes,  obtain  the  needed  additional  facts.  Create  a 
first-draft  diagram  by  first  listing  all  data  and  objects  related  to  the  function  being 
decomposed.  Take  care  that  the  list  covers  the  entire  topic  of  the  parent  box  so  that  no 
portion  is  lost  in  the  decomposition.  Then  draw  boxes  which  associate  candidate  sub¬ 
function  names  with  appropriate  data  and  objects  from  the  list,  and  draw  arrows  between 
the  boxes. 

To  derive  the  clearest  possible  diagram,  modify  or  re-draw  the  diagram  several  times  until 
satisfied.  Split  (break  up  a  box  into  two  or  more  parts)  and  cluster  (combine  two  or  more 
parts  into  a  single  box)  until  satisfied.  Split  and  cluster  until  you  express  the  parent 
function  in  three  to  six  boxes. 

Generate  portions  of  more  detailed-level  diagrams  to  explore  points  which  need 
clarification.  Create  several  (3  or  4)  diagrams  as  a  set,  rather  than  one  diagram  at  a  time. 

B. 2.1.5  Creating  Supporting  Material 

Eventually,  each  diagram  will  be  accompanied  by  a  page  of  narrative  text,  glossary  and, 
perhaps,  FEOs.  The  text  associated  with  the  A-0  diagram  should  complete  the  model’s 
orientation  and  is  written  when  the  A-0  diagram  is  created.  The  text  complements  the 
context  (expressed  in  A-0  itself)  by  expanding  upon  the  stated  viewpoint  and  purpose  of 
the  model. 

Text  for  every  other  diagram  (including  AO)  is  quite  different.  It  tells  a  brief,  concise  story. 
It  does  not  duplicate  what  the  diagram  already  says  by  merely  describing  each  box  function 
in  words,  but  rather  weaves  through  its  patterns.  At  every  level,  this  captures  the 
viewpoint  in  a  way  that  furthers  the  purpose.  A  graphic  diagram  may  or  may  not  have  an 
associated  text  diagram. 

The  glossary  explains  the  definitions  the  author  gives  to  functions  and  data/objects  in  a 
diagram.  These  definitions  are  important  because  the  terminology  used  in  the  model  may 
have  a  completely  different  meaning  in  one  company  from  the  meaning  in  another 
company.  Terminology  often  differs  among  units  or  disciplines  within  the  same  company. 

FEOs  are  diagrams  that  highlight  a  particularly  interesting  or  subtle  aspect  of  a  diagram. 
They  are  not  bound  by  IDEF  box  and  arrow  syntax  and  may  contain  partial  arrow 
structures  and  notes  to  emphasize  their  point. 
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B. 2.1.6  Selecting  a  Box  to  Detail 


Given  a  complete  parent  diagram,  “firm  up”  the  higher  levels  before  over-committing  to 
details.  That  is,  given  AO,  emphasize  work  on  Al,  A2,  A3.  Decomposing  A1  into  All, 
Alll,  should  be  done  later.  This  avoids  potential  rework  should  changes  be  made  to 
higher  level  diagrams. 

Keeping  an  even  depth  is  not  a  strict  rule.  The  amount  of  depth  at  any  time  depends  on 
whether  more  depth  would  capture  meaning  better  than  one  diagram.  Don't  put  off  doing  a 
lower  level  diagram,  e.g.,  Alll,  but  sketch  while  the  ideas  are  fresh.  The  important  thing 
is  to  treat  all  such  forays  as  sketches  until  the  “horizontal”  even  level  is  confirmed.  Be 
ready  to  rework  the  lower  level  material  if  it  conflicts  with  higher  level,  e.g.,  Al,  A2,  A3. 

Two  guidelines  are  helpful  in  deciding  which  box  to  detail: 

1 .  Start  with  the  “hard  part”  -  the  part  that  is  least  familiar  or  is  least  clear. 

2.  Select  the  box  whose  detail  will  give  the  most  information  about  other 
boxes. 

The  simpler  topics  can  be  more  easily  decomposed  later,  with  less  risk  of  error  or 
oversight,  and  can  be  easily  manipulated  to  fit  the  decomposition  of  the  more  complex 
issues. 

B.2.1.7  Author  Activities 
B.2.1.7.1  Data  Gathering  Phase 

Read  Background:  The  author  gathers  information  about  the  subject  matter  by  reading 
source  information. 

Interview:  The  author  personally  interviews  an  expert  on  the  subject  matter. 

Think:  Digest  the  information  obtained  from  reading  and  interviews  before  actual 
diagramming  begins. 

Pick  Box:  Decide  which  box  is  the  appropriate  one  to  detail  based  on  information  obtained. 

B.2.1.7. 2  Structuring  Phase 

Draw:  This  encompasses  the  actual  creative  process  of  generating  a  diagram.  It  is  not 
limited  only  to  drawing  boxes  and  arrows.  It  also  includes  the  listing  of  random  data 
elements,  making  sketches,  etc.,  which  precede  drawing  boxes  and  arrows. 

Re-draw:  This  covers  the  digestive  stage  of  diagramming  and  corresponds  to  editing  and 
reworking  of  verbal  text.  The  activity  here  is  concerned  not  with  creating,  but  with 
graphical  editing  and  rearranging  for  clarity. 

Fix  Master:  This  applies  to  the  modification  of  master  drawings  to  incorporate 
improvements.  It  is  primarily  a  mechanical  operation,  consolidating  the  results  of  separate 
re-drawings,  often  in  response  to  reader  comments. 
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B. 2. 1.7.3  Presentation  Phase 


Write  and  Edit  TextfText  accompanying  any  diagram  should  be  precise.  Editing  will  often 
alleviate  unnecessary  detail  and  redundancy. 

Assemble:  Assemble  any  material,  diagrams,  node  trees,  glossaries,  text,  etc.,  relevant  to 
the  subject.  Include  a  completed  Cover  Sheet. 

B. 2. 1.7.4  Interaction  Phase 

React:  This  refers  to  the  author  reacting  to  comments.  It  is  a  combination  of  reading  and 
annotating  reactions  to  the  comments  in  response  to  readers. 

Talk:  This  represents  time  spent  when  an  author  and  reader  actually  get  together  and  talk 
about  author  reactions  to  the  comments. 

Group  Meetings:  This  is  the  time  spent  in  group  meetings  reviewing  progress  or 
brainstorming  next  steps.  The  minutes  of  the  group  meetings  will  identify  the  subject  matter 
under  discussion. 

B.2.2  Drawing  an  IDEFO  Diagram 

Diagram  creation  is  the  most  subjective  and  creative  activity  of  the  modeling  process.  It  is 
open  to  wide  variations  between  individual  authors.  No  one  set  of  steps  will  work  equally 
well  for  all  authors.  The  steps  presented  here  are  a  proven  sequence  and  are  designed  to 
assist  a  new  author  in  drawing  IDEFO  diagrams. 

a.  Create  a  relevant,  but  not  yet  structured  list  of  data.  List  items  within  the 
context  of  the  parent  box  that  first  come  to  mind.  Group  items,  if  possible, 
to  show  similarities. 

b.  Name  functions  that  act  on  the  listed  data  and  draw  boxes  around  the 
names. 

c.  Sketch  appropriate  arrows.  As  each  box  is  drawn,  leave  arrow  “stubs”  to 
make  the  box  more  meaningful.  Make  complete  connections  as  it  becomes 
obvious  what  the  diagram  is  saying. 

d.  Draft  a  layout  that  presents  the  clearest  box  and  arrow  arrangement.  Bundle 
arrows  together  if  the  structure  is  too  detailed.  Leave  only  the  essential 
elements,  and  modify  diagram  as  necessary. 

e.  Create  text,  glossary  and  FEO  diagrams,  if  necessary,  to  highlight  aspects 
which  are  important.  Propose  changes,  if  needed,  in  the  parent  diagram. 

B.2.2. 1  Generating  Function  Boxes 

Function  boxes  are  generated  using  the  major  sub-functions  of  the  parent.  As  sub-function 
names  are  written,  draw  boxes  around  them  to  form  the  start  of  an  actual  diagram.  At  this 
stage  the  number  of  boxes  is  immaterial.  They  can  be  modified  by  clustering  and  splitting 
to  conform  to  the  three-to-six-box  rule. 

Clustering  will  group  two  or  more  boxes  to  form  a  single  box.  Its  goal  is  to  cluster  related 
functions  into  a  single,  more  general  function.  It  eliminates  premature  detail  which 
obscures  the  message  to  be  conveyed  at  this  level. 
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Splitting  will  break  a  single  box  into  two  or  more  parts.  It  is  the  inverse  of  clustering.  Its 
goal  is  to  provide  more  detail  to  present  sufficient  understanding  of  the  subject  being 
decomposed. 

Review  the  resulting  set  of  function  boxes.  Look  for  good  balance  between  the  factors 
chosen.  See  if  the  names  can  be  made  more  specific.  Use  special  terms  and  abbreviations 
only  when  needed  to  promote  communication  with  the  intended  audience  and  only  at  the 
detailed  diagram  levels.  Do  not  use  them  at  the  highest  (A-0  and  AO)  levels.  Carefully 
define  special  terms  in  the  glossary. 

In  all  cases,  make  the  function  box  names  verbs  or  verb  phrases.  Whenever  the  phrase  can 
be  interpreted  as  either  a  verb  or  a  noun,  use  the  notation  “(v)”  to  signify  the  intended  verb 
usage. 

Boxes 

1 .  In  most  cases,  lay  out  boxes  diagonally  from  upper  left  to  lower  right. 
While  any  layout  which  makes  clear  the  author’s  intent  is  acceptable, 
vertical  or  horizontal  formats  tend  to  crowd  arrows  and  hinder  good 
structured  analysis  style. 

2.  Boxes  placed  in  the  upper  left  “dominate”  boxes  placed  lower  and  to  the 
right  through  the  control  arrows  that  link  them.  This  standard  style  makes  it 
easier  for  readers  to  understand  your  meaning. 

3 .  Number  each  box  in  its  lower  right  inside  corner.  Assign  the  box  numbers 
on  a  diagram  from  left  to  right  and  from  top  to  bottom.  This  will  help 
define  the  node  number  for  each  box.  The  leading  digits  of  the  box’s 
complete  node  number  are  the  same  as  this  diagram’s  node  number.  The 
last  digit  of  the  node  number  is  this  box  number.  If  the  box  in  Figure  BIO 
appears  in  diagram  A4,  then  the  complete  node  number  for  this  box  would 
be  A42. 


Name 

2 

A42 


Figure  BIO.  Box  Number  and  Node  Number 

4.  On  working  or  draft  copies,  write  the  node  number  or  C-number  below  the 
lower  right  comer  of  any  box  that  is  detailed.  The  C-number  DRE  indicates 
the  specific  version  of  the  diagram  that  is  intended. 

5 .  No  diagram  may  contain  more  than  six  boxes. 

B.2.2.2  Creating  Interface  Arrows 

Sketch  interface  arrows  connecting  to  each  individual  box.  Connect  ends  of  arrows  to 
show  which  outputs  supply  which  inputs  and  controls. 
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Recall  that  input  data/objects  are  transformed  by  the  function  to  produce  the  output.  If  an 
arrow  contains  both  input  and  control  data/objects,  show  it  as  a  control.  If  it  is  uncertain 
whether  an  arrow  is  a  control  or  an  input,  make  it  a  control.  If  it  is  unclear  whether  or  not  a 
particular  data  or  object  arrow  is  needed  at  all,  leave  it  out  (as  long  as  it  is  not  the  only 
control). 

Output  arrows  show  the  results  of  possible  activations  of  the  function.  The  syntax  for 
output  arrows  does  not  indicate  which  patterns  of  output  arrows  may  occur  under  which 
circumstances.  If  the  sequence  is  of  particular  interest,  draw  a  FEO  illustrating  the  pattern. 
Do  not  worry  about  sequence.  Just  make  sure  that  all  important  cases  are  allowed  by  the 
diagram. 

Bundle  groups  of  related  arrows  whenever  possible.  The  most  common  mistake  when 
creating  arrows  is  to  make  the  arrow  structure  or  the  arrow  labels  too  detailed.  The  level  of 
detail  of  arrows  should  match  the  level  of  detail  of  boxes.  At  high  levels,  both  box  names 
and  arrow  labels  will  be  general. 

As  a  final  check,  compare  all  arrows  to  the  data  list  to  insure  that  each  correct  data  item 
appears.  Elements  that  do  not  appear  either  are  inappropriate  for  this  level  of  detail  or  were 
overlooked  when  creating  the  arrows. 

Think  control  and  constraint,  not  flow. 

A  basic  rule  for  layout  of  the  arrow  structure  is  “constrain,  don’t  sequence.”  That  is,  make 
the  diagram  structure  show  relationships  that  must  be  true  no  matter  which  sequence  is 
followed. 

Even  though  something  must  progress  from  stage  to  stage  to  reach  some  desired  end  result, 
try  to  express  the  constraints  that  must  be  satisfied  or  the  invariant  properties  that  must  be 
true  rather  than  some  one  specific  sequence  of  steps  that  will  yield  that  result. 

The  reason  is  that  all  boxes  may  be  active  simultaneously.  Thus,  sequence  has  no 
meaning. 

It  is  always  more  powerful  to  constrain  than  to  sequence.  Wherever  possible,  diagrams 
should  be  created  that  say  the  right  thing  regardless  of  what  steps  are  taken  first.  Clearly, 
this  is  better  than  restricting  to  only  one  of  the  possible  sequences. 

Often,  it  is  easiest  at  first  to  think  of  sub-function  actions  in  a  particular  sequence  to  get 
unstuck  and  get  something  on  paper.  This  may  be  a  good  way  to  get  going,  but  always 
rework  the  first  attempt  into  a  constraint  structure. 

Label  carefully. 

Subordination  of  unneeded  details  highlights  the  meaningful  ones.  Don’t  clutter  your 
diagrams  with  too  much  information  and  too  many  arrows.  Don’t  spend  too  long  on  a 
single  level.  Everything  need  not  be  expressed  at  once  to  avoid  being  incomplete  and 
misunderstood.  The  whole  point  of  the  discipline  is  to  get  everything  said,  eventually. 

Also,  if  there  is  too  much  in  a  diagram,  it  becomes  rigid.  If  this  is  allowed  to  happen,  the 
diagram  is  weakened.  Strength  comes  from  the  structure.  This  can  be  accomplished  by 
leaving  details  to  the  sub-functions.  Do  iterate  between  high-level  diagrams  and  sub¬ 
functions  that  fill  out  the  details. 
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Leave  out  questionable  arrows. 


It  is  often  hard  to  determine  whether  to  show  an  arrow  or  not.  The  easiest  way  to  handle 
the  arrow  question,  is  “When  in  doubt,  leave  it  out.”  If  the  arrow  isn’t  really  essential  to 
the  main  backbone,  if  there  are  questions  about  it,  it  is  probably  incorrect  to  include  it. 

Incorrect  omission  of  a  questionable  arrow  now  won’t  cause  permanent  damage.  The  need 
for  the  arrow  will  be  clearer  in  considering  sub-functions  and  the  ICOM  discipline  will 
force  the  arrow  back  up  to  this  level.  At  that  time,  there  will  be  no  question  about  it. 

B.2.2.3  Level  of  Effort 

The  initial  goal  in  generating  a  diagram  should  be  a  clear  diagram  that  represents  a  definite 
message  and  does  not  violate  any  syntax  rules.  When  the  diagram  is  finished,  the  critical 
guidelines  of  reading  and  review  by  others  can  be  used  to  improve  the  first  try.  Most 
diagrams  can  be  modified  to  make  a  second  version  that  is  in  some  sense  better  than  the 
first.  The  first  will  rarely  be  the  very  best. 

As  skill  levels  develop,  first  diagrams  get  better  and  authors  feel  more  comfortable  using 
IDEFO.  Reworking  of  diagrams  will  always  be  a  necessary  part  of  the  process.  The  key 
idea  is  to  use  a  review  cycle  to  make  progress  on  paper.  In  a  series  of  orderly  advances,  all 
of  the  important  aspects  will  be  properly  handled. 

IDEFO  is  a  thought-forming  methodology,  not  just  a  diagram-making  exercise.  Putting 
thoughts  on  paper  and  letting  the  notation  and  discipline  work  is  a  move  towards  a 
satisfactory  resolution.  Rely  on  an  ability  to  ask  good  questions,  rather  than  on  the 
expectations  of  providing  “perfect”  answers. 

B.2.3  Re-Drawing  an  IDEFO  Diagram 

B.2.3.1  Modifying  Boxes 

When  first  creating  a  diagram,  3-6  function  boxes  of  approximately  the  same  level  of  detail 
are  derived.  Clustering  and  splitting  will  provide  a  boundary  which  is  more  easily 
understood  or  which  will  provide  a  simpler  interaction  between  the  function  boxes. 

Most  often,  clustering  and  splitting  work  together.  Boxes  are  split  and  the  resulting  pieces 
clustered  into  new  boxes  which  more  closely  convey  the  intended  message.  The  same 
subject  matter  is  covered,  but  pieces  are  grouped  in  a  more  understandable  way. 

Split  and  rephrase. 

It  is  important  that  all  of  the  boxes  of  a  diagram  have  a  consistent  flavor.  Changes 
elsewhere  should  not  make  an  existing  sub-function  seem  out  of  place.  Split  and  rephrase 
to  restore  the  balance. 

Sometimes  a  box  does  not  flow  with  the  other  boxes  of  the  current  diagram.  Frequently 
the  trouble  is  that  other  aspects  have  undergone  change  and  clarification.  That  which  earlier 
was  a  good  idea,  now  has  the  wrong  slant  or  flavor. 

Divide  the  offending  box  by  splitting  it  into  two  or  more  pieces,  one  of  which  still  contains 
the  essence  of  the  original  idea,  but  more  pertinently  and  concisely.  Do  expect  to  change 
the  wording  of  the  box  (or  boxes).  With  the  separation,  new  ideas  become  clearer  and 
mesh  more  closely  with  related  boxes. 
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Cluster  and  replace. 


A  solid  abstraction  is  both  clearer  and  more  powerful  than  premature  detail.  Cluster  related 
boxes  and  replace  by  a  single  encompassing  box. 

Frequently  a  good  level  of  abstraction  can  be  made  even  better  by  clustering  several  boxes 
into  a  more  general  view  and  postponing  the  details  to  the  next  level  down.  Draw  a  line 
around  the  cluster  and  replace  them  all  with  one  box,  suitably  named.  The  extra  level  is  not 
an  added  complexity.  It  is  a  better  representation  because  the  structure  has  been  shown 
more  clearly. 

This  phenomenon  arises  often  in  conjunction  with  splitting  and  is  one  of  the  most  powerful 
methods  of  explaining  functions. 

B.2.3.2  Bundling  Arrows 

Both  arrows  and  boxes  should  be  at  a  corresponding  level  of  abstraction  in  a  diagram. 
There  are  two  basic  ways  to  achieve  this: 

1 .  Bundle  arrows  with  the  same  source  and  destination  under  a  single  more 
general  label,  and  make  one  arrow. 

2.  Rename  some  boxes  (using  Split  and  Cluster)  to  better  distribute  the  sub¬ 
functions  and  re-label  resulting  arrows. 

It  is  seldom  true  that  an  excess  of  arrows  indicates  a  mistake.  It  may  be  that  they  are  both 
accurate  and  precise.  But  it  is  always  true  that  an  excess  of  arrows  is  bad  if  the  message  is 
obscured.  The  ability  of  readers  to  understand  what  is  being  said  should  guide  the  number 
of  arrows  used. 

B.2.3.3  Proposing  Modifications  to  the  Context 

The  detailed  understanding  revealed  by  creating  a  new  diagram  may  uncover  errors  or 
oversights  in  the  parent  diagram.  Parent  modification  is  a  natural  and  anticipated  event. 
When  creating  the  arrow  structure,  the  rule  is  that  “if  there  is  any  doubt  whether  an  arrow  is 
needed  by  a  function  box,  leave  it  out  -  later  detailing  will  demonstrate  whether  or  not  the 
arrow  is  really  needed.”  This  is  the  point  where  such  questions  are  resolved  for  a  specific 
reason  rather  than  through  the  former  speculation. 

Parent  diagram  changes  may  present  various  degrees  of  difficulty.  If  the  change  can  be 
accommodated  by  a  revision  to  the  immediate  parent  only,  this  is  simpler  than  a  revision 
which  involves  more  remote  diagrams  as  well.  When  proposing  a  change,  think  it  through 
carefully  and  assess  its  complexity.  Substituting  simple  changes  for  major  ones  can  harm 
the  quality  of  the  decomposition.  When  the  correction  is  completed,  check  all  boundary 
connections  to  insure  that  ICOM  codes  are  properly  shown.  Inform  other  authors  working 
on  the  diagram  of  the  changes. 

Always  have  in  mind  the  parent  diagram  for  the  box  being  detailed.  It  will  aid  in  the 
creation  process.  If  the  detailed  diagram  doesn’t  fit  the  context,  either  the  current  work  or 
the  context  is  wrong.  Change  the  context  or  change  the  current  work.  They  must  match. 
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B.2.3.4  ICOM  Syntax  for  Connecting  Diagrams 

An  important  aspect  of  understanding  diagrams  is  the  ability  to  find  and  understand  facts 
that  are  needed.  Node  numbers  show  the  structure  of  the  function  decomposition  (box 
detailing).  The  arrow  network  provides  interface  connections. 

ICOM  codes  are  written  on  all  arrows  having  one  end  unconnected  on  the  diagram.  These 
boundary  arrows  connect  the  arrow  network  across  diagrams.  Each  boundary  arrow  is 
labeled  with  an  ICOM  code  to  specify  the  connection  of  the  arrow  to  the  parent  box. 

B.2.4  Graphic  Layout 

Lay  out  the  boxes  diagonally  according  to  the  constraint  structure,  from  the  upper  left  to 
lower  right.  Control  feedbacks  go  up  and  left,  and  input  feedback  arrows  (which  model 
memory)  go  down  and  left.  At  this  point,  number  the  boxes  from  left  to  right. 

It  is  best  to  start  this  layout  with  the  most  heavily  used  constraint  arrows  only,  adding  less 
used  paths  later.  This  subset  of  the  arrows  will  permit  the  box  position  to  be  determined. 
Draw  all  boundary  arrows  shown  on  the  parent  diagram  and  then  add  the  remaining 
arrows. 

B.2.4. 1  Constraints  on  the  Diagram 

1 .  Function  boxes  shall  always  have  control  arrows,  though  they  need  not  always 
have  inputs. 

2.  When  an  entry  arrow  serves  both  control  and  input  functions,  show  it  as  control. 
When  in  doubt,  make  it  control.  An  arrow  appearing  on  a  parent  box  as  control  can 
appear  on  the  next  level  as  control  or  input  or  both,  depending  on  its  relationship  to 
sub-functions  at  that  level. 

3 .  In  general,  do  not  split  an  arrow  into  both  a  control  and  an  input  to  the  same  box. 
This  detail  is  best  shown  on  a  lower  level  diagram  where  the  destination  of  each 
branch  and  the  reason  for  the  split  will  appear.  When  it  must  be  done  to  make  the 
parent  more  meaningful,  choose  labels  for  the  two  branches  that  will  convey  your 
important  decision. 


4 .  Iterated  activity  (memory  storage  or  feedback)  may  be  shown  as: 


5 .  Try  to  avoid  redundancies  such  as: 
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X 


MAKE 

X 

X 

or 


_ ! _ 

CONSIDER 

X 


In  these  cases,  the  trivial  box  names  merely  repeat  the  message  conveyed  by  placement  of 
the  arrows.  A  little  additional  thought  will  usually  produce  more  informative  box  names. 

B.2.4.2  Arrow  Placement 


1. 

2. 

3. 

4. 


Draw  arrows  along  horizontal  and  vertical  lines,  not  diagonally  or  as  curves  (except 
at  corners). 


Place  arrow  comers,  crossings  and  labels  a  reasonable  distance  away  from  boxes. 


Don’t  use  the  keywords,  i.e.,  “data”,  “function”,  “input”,  “output”,  “control 
“mechanism”  in  names  or  labels,  unless  absolutely  necessary. 


IIU 


or 


If  an  arrow  is  long,  label  it  twice. 


Report 


Report 

- ►  02 


5 .  Place  ICOM  codes  at  the  unconnected  ends  of  arrows. 

Cl 


11 

12 


►  01 


6.  Connect  open-ended  boundary  arrows  to  show  all  the  places  affected.  Readers  may 
miss  connections  otherwise. 


rather  than 


7.  Space  parallel  arrows  adequately.  They  are  hard  to  follow  visually  if  they  are 
lengthy  and  close  together. 
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rather  than 


-► 

► 


8 .  Place  extra  arrowheads  along  arrows  where  needed  for  clarity. 

B.2.4.3  Arrow  Layout 

1 .  Bundle  arrows  with  the  same  source  and  the  same  destination  unless  the  arrow  is  of 
such  importance  that  making  it  part  of  a  pipeline  would  decrease  clarity. 


2.  Use  as  few  arrows  as  possible  on  any  one  side  of  a  box.  If  there  are  too  many, 
bundle  some,  label  with  a  suitable  abstract  label  and  fan  out  branches  to  their 
destinations. 


\  N  N  N  rather  than 

Control  feedbacks  shall  be  shown  as  “up  and  over.” 


Input  feedbacks  shall  be  shown  as  “down  and  under.” 


J 


Mechanism  feedback  shall  be  shown  as  “down  and  under.” 


55 


4. 


T 


If  an  arrow  forks  and  feeds  into  several  boxes,  draw  it  at  the  same  relative  ICOM 
position  on  each  box,  if  possible. 


rather  than 


5 .  Lay  out  arrows  so  as  to  minimize  crossings. 

rather  than 


1 


6.  Minimize  curves  and  comers,  while  keeping  labeled  segments  clear: 


rather  than 


7 .  Use  the  expressive  potential  of  branching  arrows  when  and  if  it  is  appropriate. 
A  and  B 


rather  than 
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8. 


To  avoid  clutter  when  showing  an  arrow  which  applies  identically  to  or  is  obtained 
identically  from  every  box  on  a  diagram,  use  the  “to  all”  convention: 


-  to  all  X  - 


or 


9.  All  arrows  shall  have  curved  corners  at  joins,  forks  and  bends. 


B.2.5  Writing  Text 
B.2.5.1  Text  and  Glossary 

The  text  that  may  accompany  each  diagram  presents  a  brief  integrating  overview  of  the 
diagram,  citing  important  relations,  patterns,  or  subtle  interactions  between  the  boxes  and 
arrows. 

Preferably,  the  text  is  less  than  a  page  in  length.  It  highlights  features  that  the  author  feels 
are  of  special  interest  or  significance  by  walking  the  reader  through  the  main  ideas  of  the 
diagram.  It  does  not  duplicate  every  detail  shown  on  the  diagram  itself. 

Write  the  text  only  after  a  diagram  has  received  a  fairly  high  level  of  review  and  approval. 
Waiting  to  write  the  text  forces  the  diagram  itself  to  properly  communicate  the  intended 
message.  Text  based  on  carefully  drawn  diagrams  will  be  as  structured  and  as  organized  as 
the  diagram  itself. 
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Use  glossary  definitions  to  summarize  the  special  meanings  that  may  arise  for  key  terms, 
words,  phrases  and  acronyms  used  in  the  diagram.  A  word  or  phrase  may  have  different 
connotations  for  different  readers  of  the  diagram. 

Try  to  get  good  text  without  adding  a  FEO.  FEOs  should  be  used  to  illustrate  subtle 
aspects  that  clarify  the  intent  of  a  diagram  but  which  would  clutter  the  diagram  were  they 
included.  If  a  FEO  is  necessary,  the  text  that  accompanies  it  should  refer  to  the  related 
diagram. 

B.2.5.2  Notes  and  References 

There  are  two  kinds  of  notes,  model  notes  and  reader  notes.  Model  notes  are  discussed  in 
the  normative  section. 

In  sharp  contrast  to  the  model  notes,  which  are  part  of  the  diagram  on  which  they  appear, 
reader  notes  explicitly  are  on  the  diagram,  not  part  of  the  diagram.  Thus  they  cannot  alter 
the  meaning  of  the  diagram's  syntax  or  semantics.  As  with  model  notes,  if  the  text  of  a 
reader  note  is  to  apply  to  several  places  or  to  several  features  of  the  diagram  (including 
other  model-notes  or  reader-notes)  the  circled-note-number  (without  any  text)  may  be 
copied  and  may  be  attached  by  an  IDEFO  squiggle  —  to  each  point  of  application,  but 
only  on  the  single  diagram  on  which  the  reader-note’s  text  appears. 

By  definition,  reader  notes  are  strictly  informative,  not  normative.  They  may  be  about 
anything  at  all,  with  respect  to  the  diagram  or  model.  In  practice,  reader  notes  may  be 
about  the  modeled  subject  matter  or  about  its  modeled  presentation,  including  choice  of 
words,  layout,  accuracy,  etc. 

Reader  notes  are  denoted  by  a  number  “n”  inside  a  small  circle:  (n)  .  For  any  specific 
diagram  (and  hence  node  number),  the  numbers,  “n”,  shall  form  a  consecutive  sequence, 
starting  at  “1”.  All  readers  (including  the  author,  when  commenting  about  something) 
shall  share  the  same  reader-note  sequence  for  a  diagram.  Reader-note  numbers  for  a  node 
shall  never  be  reused  or  reassigned.  Thus  their  creation  sequence  in  the  context  of  their 
node  number  is  a  permanent  record  of  reader/author  discussion  regarding  that  node. 

A  standard  notation  is  used  in  writing  text  and  notes  to  refer  to  diagrams  and  specific  parts 
of  diagrams.  References  are  based  on  box  numbers,  ICOM  codes,  node  numbers,  and 
note  numbers. 

For  example, 


02 

means 

The  boundary  arrow  with  ICOM  code  02 

211 

means 

Box  2  Input  1 

202  to  3C1 

means 

The  arrow  from  202  to  3C 1 

0 

means 

Model  Note  n 

Ini 

means 

Model  Note  n  (alternate  notation) 

(n) 

means 

Reader  Note  n  (alternate  notation) 

® 

means 

Reader  Note  n 
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QA/A21.3C2  means 


A42.® 


A42.  3 


A42.3 


In  “QA”  model  on  diagram  A21,  see  Box  3  Control  2 
means  On  diagram  A42  in  this  model,  see  reader  note  3 

means  On  diagram  A42  in  this  model,  see  model  note  3 

means  On  diagram  A42  in  this  model,  see  Box  3 


These  items  may  be  used  individually  if  they  refer  to  the  current  diagram  (e.g.,  in  model 
notes  or  text).  Otherwise  they  should  be  preceded  by  node  number,  and  if  necessary,  by 
model  name.  A  period  is  used  to  mean  “see”  a  certain  thing  on  the  specified  diagram. 
For  example: 


MFG/A2 1 .3C2  means  In  model  “MFG”,  on  diagram  A2 1 ,  see  Box  3 

Control  2. 

Each  reference  needs  only  as  many  fields  as  are  necessary  to  be  completely  unambiguous. 
The  fullest  form  is: 


ACCT/(A2 1  =BT56).  1 02  to  4C3 

which  means  in  model  “ACCT,”  diagram  A21,  C-number  BT56,  “see”  the  arrow  from  Box 
1  Output  2  to  Box  4  Control  3. 

Embed  neat  and  complete  references  in  the  wording  of  the  text,  glossary,  and  FEO  pages, 
e.g.,  "The  influence  (2o3  to  lc2  and  3c2)  of  this  cost  on  the  ultimate  price  (o2)  is  of 
concern."  This  traces  the  third  output  of  box  2,  through  boxes  1  and  3,  to  the  02  boundary 
arrow  as  the  sentence  is  read.  When  finished  with  the  text  go  through  and  add  box-number 
references  to  tie  the  text  to  the  diagram  exactly. 

Most  of  the  time  a  simple  box  number  (“Box  3”)  or  a  reference  to  a  couple  of  arrows  is 
sufficient  (“Box  3,  01  and  C2”).  When  a  reader  needs  to  actually  “see”  the  other  diagram, 
use  the  of  the  reference  language. 

Just  as  ICOM  coding  naturally  extends  the  node-number-based  referencing  scheme,  the 
model-note  and  reader-note  notations  permit  them  to  be  referenced. 

For  example, 

A21.3C2  121  (5)  reply 

carries  the  previous  example  (“On  diagram  A21,  see  Box  3  Control  2”)  to  the  case  in  which 
the  reader  references  the  diagram-author’s  reply  to  reader-note  #5  (perhaps  added  by  the 
second  reader  of  the  diagram)  which  commented  on  the  author’s  model-note  #2,  regarding 
the  control  in  question!  In  this  example,  “reply”  shows  the  use  of  brief  natural  language 
expressions  in  the  reference  language. 

This  example  also  illustrates  the  use  of  abbreviations  Ini  for  0  (model-notes)  and  (n)  for 
(n)  (reader-notes)  for  textual  reference  purposes.  These  abbreviations  permit  easier 
preparation  of  references  to  notes  using  standard  word  processors.  References  to  notes  in 
IDEFO  text  and  written  correspondence  are  examples  of  textual  references. 
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B.3  Data  Collection  for  IDEF  Modeling 

B.3.1  Introduction 

When  analyzing  or  designing  any  system,  it  may  be  necessary  to  obtain  or  verify  facts 
about  the  system  or  subject  matter  at  hand.  There  are  many  sources  of  factual  information. 

One  might  do  the  following: 

•  Read  existing  documents,  using  each  table  of  contents  and  index  to  locate 
needed  information. 

•  Observe  the  system  in  operation,  if  it  already  exists. 

•  Survey  a  large  group  of  people,  through  questionnaires  or  other  such 
means. 

•  Talk  to  one  or  more  experts  who  possess  the  desired  knowledge. 

•  Use  whatever  is  already  known  by  the  author. 

•  Guess  or  invent  a  hypothetical  description,  and  ask  readers  to  help  bring  it 
closer  to  reality. 

Of  all  these  methods,  the  most  important  is  face-to-face  interaction  with  an  expert.  Seldom 
will  all  existing  information  be  written.  Preconceived  notions  that  are  reflected  in 
questionnaires  are  often  faulty. 

A  key  part  of  interviewing  is  to  record  the  information  obtained.  This  can  be  done  either  as 
informal  notes,  as  activity  and  data/objects  lists,  as  a  formal  matrix  of  functions,  or  as 
diagram  sketches. 

B.3. 2  The  Interview  Process 

The  purpose  of  an  interview  is  to  gather  information  from  an  individual  who  possesses  an 
expertise  considered  important  to  the  analytical  effort.  There  are  four  types  of  interviews 
that  might  be  conducted  during  the  course  of  performing  the  analysis  phase  of  an  IDEF 
project. 

(a)  Fact  Finding  for  understanding  current  operations.  This  type  of  interview  is 
used  to  establish  the  content  of  a  Current  Operations  Model  or  to  help 
understand  the  existing  environment. 

(b)  Problem  Identification  to  assist  in  the  establishment  of  future  requirements. 
This  type  of  interview  is  used  to  validate  the  Current  Operations  Model  and 
to  provide  the  foundation  for  a  Future  Operations  Model. 

(c)  Solution  Discussion  regarding  future  system  capabilities.  This  type  of 
interview  is  used  to  establish  the  content  of  a  Future  Operations  Model. 

(d)  IDEF  Author/Reader  Talk  Session.  This  type  of  interview  is  used  to 
resolve  problems  which  have  surfaced  during  the  construction  of  an  IDEF 
model. 
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The  reason  for  identifying  types  of  interviews  is  that  during  the  course  of  performing  an 
actual  interview,  ingredients  of  each  type  appear.  The  respondent  might  tell  the  interviewer 
facts  about  a  given  system  in  terms  of  problems.  Also,  the  respondent  might  identify 
problems  in  terms  of  solutions  to  the  problems.  By  constantly  classifying  the  respondents’ 
remarks,  the  interviewer  can  better  appreciate  the  expert's  point  of  view. 

B.3.3  The  Interview  Kit 

A  “standard”  interview  kit  can  be  used  for  recording  the  interview.  It  may  be  stored  in  an 
interview  file  and  it  may  be  distributed  to  appropriate  project  individuals.  This  distribution 
might  include  other  members  on  the  analysis  team  or  even  the  interview  respondent  for 
corrections,  additions  and  deletions.  The  interview  kit  would  contain: 

1 .  Cover  Page  (Kit  cover) 

2 .  Interview  and  Record  Follow-up 

(a)  Interviewer  Name  (IDEF  Author  Name) 

(b)  Interview  Date  (IDEF  Diagram  Date) 

(c)  Interview  Duration  (Start  time,  End  time) 

(d)  Respondent  Name 

(e)  Respondent  Title  and  Organizational  Responsibility 

(f)  Respondent  Telephone  Number  and  Extension 

(g)  Additional  Sources  of  Information  Identified 

( 1 )  Documents — Title  and  Location 

(2)  Other  Interviewees — Name,  Title,  Organizational 
Responsibility,  Address,  Telephone  Number 

(h)  Essential  Elements  of  Information — A  Summary  of  the  key  points 
covered  in  the  interview 

(i)  Follow-up  questions  and/or  areas  of  concern  either  not  covered 
during  the  interview  or  postponed 

(j)  New  Terms  for  Project  Glossary 

3 .  Activity  and  Data/Objects  List 

4 .  Interview  Agenda  (developed  in  preparation  for  interview). 

5 .  Interview  Notes  and  Rough  Diagrams 
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ANNEX  C  -  REVIEW  CYCLE  PROCEDURES  AND  FORMS 

C.l  IDEF  Teamwork  Discipline 

The  development  of  any  IDEF  model  is  a  dynamic  process  which  requires  the  participation 
of  more  than  one  person.  Throughout  a  project,  the  draft  portions  of  a  model  are  created 
by  authors  and  distributed  to  others  (project  members,  experts  in  the  subject  matter, 
management,  etc.)  for  review  and  comment.  These  draft  portions  of  a  model  are  called 
Kits  and  may  contain  diagrams,  text,  glossary  or  any  other  information  the  author  feels  is 
pertinent  to  the  development  of  the  model. 

It  requires  brief  training  and  modest  experience  to  correctly  read  and  understand  IDEFO 
models.  Such  knowledgeable  understanding  is  essential  if  the  team-supplied  quality 
assurance  of  IDEF  modeling  is  to  be  realized.  Everyone  suitably  advanced  in  correct 
reading  skills  is  called  a  “reader”. 

The  IDEF  teamwork  discipline  identifies  all  persons  interested  in  the  review  of  a  model  as 
reviewers.  Reviewers  who  are  assigned  to  make  a  written  critique  of  a  Kit  are  called 
commenters.  Reviewers  who  receive  a  Kit  for  information  only  are  not  expected  to  make 
written  comments  and  are  called  readers.  The  author  and  the  commenters  share 
responsibility  for  the  quality  of  the  model.  Through  their  acceptance  of  the  agreed  result, 
the  other  reviewers  share  accountability  for  the  utility  of  the  results. 

The  discipline  requires  that  each  person  expected  to  make  comments  about  a  Kit  shall  make 
them  in  writing  using  reader  notes  and  submit  them  to  the  author  of  the  Kit.  Writing  on 
the  reader’s  copy,  the  author  responds  to  each  note  in  writing  (a  simple  check  mark,  for 
agreement;  otherwise,  a  note  in  reply).  This  cycle  continues,  encompassing  all  Kits 
pertaining  to  a  particular  model,  until  the  model  is  complete  and  recommended  for 
publication. 

At  regular  intervals  during  the  evolution  of  a  model,  the  master  copy  of  the  latest  version  is 
placed  in  the  library,  and  a  copy  is  disseminated  in  the  form  of  a  Kit,  which  is  sent  to 
readers  to  assist  them  in  maintaining  current  information  about  the  model.  As  the 
comments  on  each  kit  are  reviewed  by  the  author,  he  makes  changes  in  the  master  copy  of 
the  model  to  incorporate  corrections  and  changes.  Another  kit  which  includes  the  latest 
changes  is  then  distributed  to  the  list  of  readers.  More  detail  is  added  by  the  creation  of 
more  diagrams,  text  and  glossary.  More  comments  are  made;  more  changes  are  included. 
The  end  effect  of  this  process  for  organized  teamwork  is  a  high  assurance  that  the  final 
IDEF  models  are  valid,  well  expressed,  and  that  a  consensus  has  been  reached  by  the  set  of 
readers  who  have  been  included  in  the  review  cycle. 

C.2  The  IDEF  Kit  Cycle 

In  creating  a  document,  materials  written  or  gathered  by  an  author  are  distributed,  in  the 
form  of  a  Standard  Kit,  to  commenters,  reviewers  and  other  readers.  Commenters  review 
the  material  and  write  comments  about  it.  The  commenters  return  the  Kit  to  the  author  who 
reacts  to  comments  and  may  use  the  comments  to  revise  or  expand  the  material.  The  Kit  is 
returned  to  the  commenter  with  the  reactions  from  the  author.  Readers  may  return 
comments  to  the  author  as  well,  but  this  is  not  required.  This  is  known  as  a  Kit  Cycle 
(Figure  Cl). 
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The  steps  of  the  Kit  Cycle  are  as  follows: 

•  The  author  assembles  the  material  to  be  reviewed  into  a  Standard  Kit.  A  cover 
sheet  is  completed.  Copies  of  the  kit  are  distributed  to  each  of  the  readers,  and  to 
the  author.  The  original  is  filed  for  reference. 

•  Within  the  response  time  specified,  the  commenter  reads  the  kit  and  writes 
comments  directly  on  the  copy  in  the  form  of  reader  notes,  in  red  if  possible. 
The  kit  is  returned  to  the  author. 

•  The  author  responds  in  writing  directly  on  each  commenter's  copy,  in  blue  if 
possible.  The  author  may  agree  with  the  comment  by  check-marking  it,  noting  it 
on  his  working  copy  and  incorporating  it  into  the  next  version  of  the  model.  If 
there  is  disagreement,  the  author  writes  a  note  of  reply  attached  to  the  reader's 
note  (no  new  note  number).  Whether  or  not  there  is  disagreement,  the  kit  is 
returned  to  the  reader,  completing  one  Reader/Author  Cycle.  (See  C.4.1.2 
regarding  reader  note  numbering.) 

•  The  reader  reads  the  author’s  responses  and,  if  satisfied,  files  the  kit. 
(Commented  kits  are  always  retained  by  the  reader.)  If  an  assigned  commenter 
does  not  agree  with  the  author’s  responses,  a  meeting  is  arranged  with  the  author 
to  resolve  differences.  If  this  cannot  be  done,  a  list  of  issues  is  taken  to 
appropriate  authority  for  decision.  The  author  is  not  obligated  to  resolve 
differences  with  every  reader,  but  commenters  are  disenfranchised  if  their 
concerns  are  not  resolved. 

This  cycle  continues  until  a  document  is  created  which  represents  the  careful  consideration 
of  all  project  members.  In  addition,  a  complete  history  of  the  process  has  been  retained. 
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The  results  of  this  Kit  Cycle  are  a  document  to  which  author  and  commenters  have 
contributed,  and,  if  necessary,  a  list  of  issues  that  require  management  action. 

Throughout  the  cycle,  a  project  librarian  handles  copying,  distribution,  filing  and  transfer 
of  kits  between  authors,  commenters,  reviewers  and  readers. 


C.2.1  Personnel  Roles 

The  roles  and  functions  of  people  involved  are: 

•  Authors  (Analysts) 

People  who  prepare  any  IDEF  model. 

•  Commenters  (Experts  or  other  Authors) 

People  knowledgeable  of  the  subject  being  modeled  from  whom  authors  may 
have  obtained  information  by  means  of  interviews,  and  have  enough  training  in 
an  IDEF  technique  to  offer  structured  comments  in  writing.  People  assigned  to 
make  a  written  critique  of  a  kit. 

•  Readers  (Experts  or  anyone  who  wishes  to  be  on  the  reader  list) 

People  knowledgeable  of  the  subject  being  modeled  from  whom  authors  may 
have  obtained  information  by  means  of  interviews,  and  review  documents  for 
information  but  are  not  expected  to  make  written  comments. 

•  Librarian 

A  person  assigned  the  responsibility  of  maintaining  a  file  of  documents,  making 
copies,  distributing  kits  and  keeping  records. 

All  people  playing  these  roles  must  be  trained  and  experienced  IDEFO  readers,  so  they  can 
perform  the  assigned  functions  reliably. 

A  “role”  has  nothing  to  do  with  someone’s  job  title,  and  the  same  person  may  be  asked  to 
perform  several  roles.  Thus,  each  individual’s  participation  is,  in  fact,  unique  and  depends 
upon  the  kit  involved. 

C.2.1.1  Author 

An  author  interviews  experts,  analyzes  the  information,  organizes  it  into  diagrams  and 
creates  models.  An  author  may  or  may  not  be  the  source  of  the  technical  content  of  a 
document.  An  author  may  serve  only  as  an  analyst  of  acquired  information,  identifying, 
sorting  out  and  organizing  the  presentation  of  knowledge  obtained  from  experts  and 
applying  modeling  skills  in  expressing  his  understanding  in  IDEFO  terms. 

C.2.1. 2  Commenter 

Assigned  commenters  read  material  produced  by  an  author  and  verify  its  technical 
accuracy.  They  are  responsible  for  finding  errors  and  suggesting  improvements.  The  role 
of  a  commenter  is  the  key  to  producing  high  quality  results.  But  every  reader  should  note 
whether  the  author  has  followed  the  IDEF  technique  consistently;  whether  the  viewpoint 
and  purpose  have  been  adhered  to;  and  whether  errors  or  oversights  exist  which  should  be 
brought  to  the  author's  attention.  If  a  reader  is  a  trained  author,  suggesting  changes  in  the 
hierarchical  breakdown,  variations  in  activity  box  content  and  other  observations  to 
enhance  the  communication  power  and  utility  of  the  model  will  be  welcomed  by  most 
authors. 
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C.2.2  Guidelines  for  Authors  and  Readers  and  Commenters 

In  this  section,  general  guidelines  for  readers  and  authors  are  discussed — readers  may  have 
further  special  interests  as  commenters  and  reviewers  that  are  not  covered  here. 

C.2.2. 1  Reader  Guidelines 

No  set  pattern  of  questions  and  rules  can  be  adequate  for  commenting,  since  subject  matter, 
style  and  technique  vary  so  widely.  However,  guidelines  do  exist  for  improving  quality. 
The  major  criteria  for  quality  are:  Will  the  document  communicate  well  to  its  intended 
audience?  Does  it  accomplish  its  purpose?  Is  it  factually  correct  and  accurate,  given  the 
bounded  context?  Overall  guidelines  for  commenting  are: 

•  Make  notes  brief,  thorough  and  specific.  As  long  as  the  author  understands 
that  niceties  are  dropped  for  conciseness,  this  makes  for  easier 
communication  and  less  clutter. 

•  Use  the  (n)  notation  (reader  notes)  to  identify  comments.  To  write  an  (n) 
-note,  check  the  next  number  off  the  READER  NOTES  list,  number  the 
note,  circle  the  number  and  connect  the  note  to  the  appropriate  part  with  a 
squiggle  —  .  (See  Section  C.4  Standard  Diagram  Form.) 

•  Make  constructive  criticisms.  Try  to  suggest  solutions  or  point  out  sources 
of  problems,  clearly. 

•  Take  time  to  gather  overall  comments.  These  may  be  placed  on  the  cover  or 
on  a  separate  sheet.  (But  don’t  gather  specific  points  onto  this  sheet  when 
they  belong  on  the  individual  pages.)  Agenda  items  for  author/commenter 
meetings  may  be  summarized.  Make  agenda  references  specific. 

The  length  of  time  spent  critiquing  depends  on  a  variety  of  things:  familiarity  with  what  is 
being  described,  the  number  of  times  something  has  been  reviewed,  the  experience  of  the 
reader  and  author,  etc.  A  kit  returned  to  an  author  with  no  comments  other  than  the 
reader’s  signature  and  a  check  mark  means  that  the  reader  is  in  total  agreement  with  the 
author.  The  reader  should  realize  that  there  is  a  shared  responsibility  with  the  author  for  the 
quality  of  the  work. 

C.2.2. 2  Author/Commenter  Interchanges 

When  a  reader  returns  a  kit,  the  author  responds  by  putting  a  “V”  or  “X”  by  each  (n)-note 
(reader  note).  “V”  means  the  author  agrees  with  the  commenter  and  will  incorporate  the 
comment  into  the  next  version  of  the  kit.  “X”  means  the  author  disagrees.  The  author 
must  state  why  in  writing  where  the  comment  appears.  After  the  author  has  responded  to 
all  comments,  the  kit  is  returned  for  the  reader  to  retain. 


C.2.2. 3  Meeting  Guidelines 

Until  comments  and  reactions  are  on  paper,  readers  and  authors  are  discouraged  from 
conversing. 

When  a  meeting  is  required,  the  procedure  is  as  follows: 

1 .  Each  meeting  should  be  limited  in  length. 
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2 .  Each  session  must  start  with  a  specific  agenda  of  topics  which  relate  to  one 
or  more  of  the  comments  and  author  responses,  and  the  session  must  stick 
to  these  topics. 

3 .  Each  session  should  terminate  when  the  participants  agree  that  the  level  of 
productivity  has  dropped  and  individual  efforts  would  be  more  rewarding. 

4.  Each  session  must  end  with  an  agreed  list  of  action  items  which  may  include 
the  scheduling  of  follow-up  sessions  with  specified  agendas. 

5 .  In  each  session,  a  “scribe”  should  be  designated  to  take  minutes  and  note 
actions,  decisions  and  topics. 

6.  Serious  unresolved  differences  should  be  handled  professionally,  by 
documenting  both  sides  of  the  picture. 

The  result  of  the  meeting  should  be  a  written  resolution  of  the  issues  or  a  list  of  issues  to  be 
settled  by  appropriate  managerial  decision.  Resolution  can  take  the  form  of  more  study  by 
any  of  the  participants. 

C.3  IDEF  Kits 

A  Kit  is  a  technical  document.  It  may  contain  diagrams,  text,  glossaries,  decision 
summaries,  background  information  or  anything  packaged  for  review  and  comment. 

An  appropriate  cover  sheet  distinguishes  the  material  as  a  kit.  The  cover  sheet  has  fields 
for  author,  date,  project,  document  number,  title,  status  and  notes. 

There  are  two  types  of  IDEF  Kits: 

Standard  Kit  To  be  distributed  for  comment.  It  is  considered  a  “working  paper”  to  assist 
the  author  in  refining  his  total  model. 

Update  Kit  Contains  the  latest  version  of  a  model.  It  is  sent  for  information  only  and  is 
designed  to  aid  in  maintaining  current  information  about  the  total  model 
while  portions  of  the  model  are  being  processed  through  the  Kit  Cycle.  The 
Update  Kit  may  include  only  those  pages  changed  since  the  previous 
updating. 

Standard  Kits  contain  portions  of  a  model  and  are  submitted  frequently  as  work 
progresses.  Standard  Kits  are  submitted  through  the  IDEF  Kit  Cycle  for  review  and  are  the 
type  referred  to  in  the  rest  of  this  annex. 

Update  Kits  are  submitted  at  regular  intervals.  These  kits  contain  the  latest  version  of  the 
model.  Recipients  of  Update  Kits  are  not  expected  to  make  comments  on  them  although 
they  may  choose  to  do  so.  Update  Kits  are  kept  by  the  recipients  for  their  files. 

C.3.1  Completing  a  Kit  Cover  Sheet 

An  appropriate  cover  sheet  distinguishes  the  material  as  a  kit.  The  cover  sheet  has  fields  for 
author,  date,  project,  document  number,  title,  status  and  notes.  Prepare  one  Cover  Sheet  for  each 
kit  submitted,  filling  in  the  following  fields  on  the  Cover  Sheet  (See  Figure  C2). 
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Working  Information 


Author  or  team  generating  the  model 
Project  name  and  task  number 
Date  of  original  submission  to  library 
Dates  of  all  published  revisions 

Status  of  model,  either  working,  draft,  recommended  for  acceptance 
or  publication  as  final  model 

Reviewer  Information 

Filing  and  copying  information 
List  of  kit  reviewers 

Schedule  date  for  various  stages  of  kit  cycle 

Content  Information 

Table  of  contents  for  the  kit 

Status  of  each  kit  section 

Comments  or  special  instructions  to  librarian 

Identification  Information 

Model  Name  (in  Node  field) 

Title  of  the  model 
C-Number 
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IDEF  COVER  SHEET  FORM 


Figure  C2.  IDEF  Kit  Cover  Sheet 
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IDEF  KIT  CONTENTS  FORM 
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Figure  C3.  IDEF  KIT  CONTENTS  FORM 
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C.3.2  How  to  Prepare  a  Standard  Kit 


To  avoid  oversights,  review  the  kit  as  if  that  were  the  only  information  available.  Catch 
any  typographical  errors.  Add  points  of  clarification  that  come  to  mind  as  brief  notes  on 
the  kit  itself.  Glossary  definitions  for  terms  that  appear  in  the  kit  should  always  be 
appended  as  support  material. 

Gather  helpful  materials  and  append  these  for  the  reader's  benefit.  Never  use  this 
supplemental  material  to  convey  information  which  should  properly  be  conveyed  by  the 
diagram  itself.  Whenever  possible,  use  the  most  natural  means  of  communication — 
diagrams — to  show  details  that  are  important  for  the  reader  in  understanding  the  concepts. 
Combine  all  material  with  a  completed  Cover  Sheet  and  Kit  Contents  Sheet  (Figure  C3)  and 
submit  to  the  Library. 

C.4  Standard  Diagram  Form 

The  IDEF  Diagram  Form  (Figure  C4)  has  minimum  structure  and  constraints.  The  sheet 
supports  only  the  functions  important  to  the  discipline  of  structured  analysis.  They  are: 

Establishment  of  context; 

Cross-referencing  between  pieces  of  paper; 

Notes  about  the  content  of  each  sheet. 

The  diagram  form  is  a  single  standard  size  for  ease  of  filing  and  copying.  The  form  is 
divided  into  three  major  sections: 

Working  Information  (top) 

Message  Field  (center) 

Identification  Fields  (bottom) 

The  diagram  form  should  be  used  for  everything  written. 


Figure  C4.  Standard  Diagram  Form 


The  form  is  designed  so  that  the  Working  Information  Fields  at  the  top  of  the  form  may  be 
cut  off  when  a  final  “approved  for  publication”  version  is  completed.  The  Identification 
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Fields  at  the  bottom  are  designed  to  show,  one  under  the  other,  when  the  forms  (with  tops 
intact  for  tacking)  are  spread  vertically  and  thumb-tacked,  in  top  down  order,  on  a  cork 
board  or  wall.  The  exposed  Identification  Field  Strips  act  as  a  thumb  index  arranged  in 
Node  Index  (outline)  order.  If  the  two-sided  page-pair  publication  format  is  followed,  with 
the  Text-and-Context  page  bottoms  toward  the  binding,  then  their  information  becomes 
visible  when  the  wall-mounted  ancestor  forms  are  lifted  up,  to  see  the  Message  Field  of 
each  diagram. 

C.4.1  Working  Information 

C.4.1.1  The  “Author/Date/Project”  Field 

This  tells  who  originally  created  the  diagram,  the  date  that  it  was  first  drawn  and  the  project 
title  under  which  it  was  created.  The  “date”  field  may  contain  additional  dates,  written 
below  the  original  date.  These  dates  represent  revisions  to  the  original  sheet.  If  a  sheet  is 
re-released  without  any  change,  then  no  revision  date  is  added. 

C.4.1.2  The  "Reader  Notes"  Field 

This  provides  a  check-off  for  reader  notes  written  on  the  diagram  sheet.  As  a  comment  is 
made  on  a  page,  the  corresponding  note  number  is  crossed  out.  This  process  ensures  that 
each  reader  note  on  a  diagram  is  assigned  a  unique  note  number,  and  that  the  note  numbers 
on  each  diagram  are  consecutive. 

C.4.1.3  The  “Status”  Field 

The  status  classifications  indicate  stages  of  approval.  They  are: 


WORKING 


DRAFT 


RECOMMENDED 


PUBLICATION 


The  diagram  is  a  major  change,  restarts  the  approval 
sequence.  New  diagrams  are,  of  course,  working  copy,  but 
also  it  is  usual  for  diagrams  to  remain  Working  for  several 
revisions  before  advancing.  A  new  author  for  a  diagram 
usually  resets  the  status  to  Working,  as  well. 

The  diagram  is  a  minor  change  from  the  previous  diagram, 
and  has  reached  some  agreed-upon  level  of  acceptance  by  a 
set  of  readers.  Draft  diagrams  are  those  proposed  by  a  task 
leader  (who  may  be  the  author).  Draft  diagrams  may 
undergo  further  revisions,  if  they  are  included  in  a  current  kit 
along  with  other  diagrams,  or  are  brought  back  into 
consideration  from  some  reader's  file,  even  though  they  are 
not  in  the  current  kit.  Draft  status  remains  until  the  diagram 
is  accepted  by  a  review  meeting  of  the  technical  committee  or 
coalition. 

Both  this  diagram  and  its  supporting  text  have  been  reviewed 
and  approved  by  a  meeting  of  the  technical  committee  or 
coalition,  and  this  diagram  is  not  expected  to  change. 

This  page  may  be  forwarded  as  is  for  final  printing  and 
publication. 
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C.4.1.4  The  “Reader/Date”  Field 


This  area  is  where  a  reader  should  initial  and  date  each  form. 

C.4.1.5  The  “Context”  Field 

A  sketch  of  only  the  box  layout  of  the  parent  diagram,  with  the  parent  box  highlighted. 
The  parent  diagram’s  node  number  is  written  in  the  lower  left  of  the  Context  Field  (Figure 
C5).  The  box  number  of  the  parent  box  may  be  written  in  the  highlighted  box,  even 
though  it  also  is  the  last  digit  in  the  child  diagram’s  node  field  entry. 


The  following  special  cases  arise:  1)  The  Context  field  of  the  required  A-0  context  diagram 
form  is  "TOP",  written  in  the  center  of  the  field.  2)  The  Context  field  of  the  optional  A-l 
high-level  context  diagram  is  A-2,  sketched,  if  there  is  such  a  higher-level  context  diagram, 
and  similarly  for  A-n,  for  n  =  2  or  greater.  3)  The  Context  field  for  the  highest-level  of 
context  diagram,  A-n,  for  largest  n  (=  1  or  greater)  is  "NONE".  See  Figure  21  for  an 
illustrative  example. 

C.4.1.6  The  “Used  At”  Field 

This  is  a  list  of  diagrams,  other  than  the  parent  context,  which  use  or  reference  this 
diagram-form  page  in  some  way. 

The  most  common  use  is  a  listing  of  one  or  more  node  references  to  sub-models  for  which 
this  child  diagram’s  parent  box  supplies  support  for  calls  into  this  child’s  details.  If 
necessary  (the  case  n=l  being  assumed  by  convention),  the  node_reference_expression 
(which  begins  with  a  “model_name/”  followed  by  a  node  number)  ends  with  “Mn”,  n 
greater  than  or  equal  to  2,  making  the  reference  into  a  complete  ICOM-code  reference  to  a 
specific  Mechanism  arrow  of  the  supported  sub-model’s  top  box.  For  example 
“TLS/A34M2”  written  in  the  Used  At  field  for  child  diagram  “MN/A211”  asserts  that 
parent  box  “MN/A21”  supplies  mechanism  support,  via  the  second  mechanism  arrow  of  its 
top  box,  to  sub-model  “TLS/A34.” 

With  such  support  to  a  remote  sub-model  supplied  by  this  Used  At  field,  then  any  child 
box  on  this  child  diagram  (or  more  generally,  even  the  parent  box  that  supplies  the  support, 
or  any  offspring  boxes)  may  be  called  upon  to  supply  details  for  some  reachable  offspring 
box  of  the  supported  box  (treated  as  the  top  box  of  a  sub-model)  whose  node  reference 
appears  in  the  Used  At  field.  A  reachable  offspring  box  is  a  box  that  is  reachable  by  a 
branching  mechanism  support  arrow  whose  source  is  ICOM-code  connected  to  the 
mechanism  support. 
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If  the  top  of  the  diagram  is  cut  off,  for  publication,  then  the  contents  of  the  Used  At  field 
must  be  copied  into  the  Message  field  as  a  HD  -note  (model  note). 

C.4.2  The  “Message”  Field 

The  Message  field  contains  the  primary  message  to  be  conveyed.  The  field  is  normally 
used  for  diagramming  with  an  IDEF  graphical  language.  However,  the  field  can  be  used 
for  any  purpose:  glossary,  checklists,  notes,  sketches,  etc.  Project  members  should  use  no 
paper  other  than  diagram  forms,  so  that  the  reference-number-based  filing  system  can 
provide  a  complete  project  record.  This  can  be  facilitated  by  IDEF  tool  support  that 
includes  E-mail  and  Bulletin  Boarding,  with  automatic  C-numbering  and  “preference”- 
settings  for  each  participant. 

C.4.3  The  “Node”  Field 

This  field  contains  the  complete  node  reference  for  the  sheet  (including  model_name,  slash, 
Node  Number,  and  “F”  (for  FEO),  “T”  (for  text)  or  “G”  (for  glossary)  — with  the  page 
number  “1”  or  “2”,  etc.  appended  at  the  end  to  indicate  overflow  pages,  if  necessary),  so 
that  the  sheet  is  uniquely  located  for  any  and  all  reference  purposes. 

C.4.4  The  “Title”  Field 

The  Title  field  contains  the  name  of  the  material  presented  on  the  Diagram  Form.  If  the 
Message  field  contains  a  diagram,  then  the  contents  of  the  Title  field  must  precisely  match 
the  name  written  in  the  parent  box. 

C.4.5  The  “Number”  Field 

C.4.5.1  The  “Number”  Field  (Large  Area) 

The  large  area  contains  the  C-number.  The  C-number  is  composed  of  two  or  three  letters 
of  the  author’s  initials  (chosen  to  be  unique  among  project  participants)  followed  by  a 
number  sequentially  assigned  by  the  author.  This  C-number  is  placed  in  the  lower  left 
corner  of  the  Number  field  and  is  the  primary  means  of  reference  to  a  sheet  itself,  because 
the  sheet  as  a  diagram  form  in  use  can  only  be  created  once.  Every  diagram  form  used  by 
an  author  receives  a  unique  C-number,  which  habitually  should  be  the  first  mark  made  on 
the  form. 

If  the  project  elects  to  track  version  history,  then  the  C-number  of  the  diagram  form  of 
which  this  sheet  is  an  altered  version  shall  be  written  parenthesized  (space  optional) 
following  the  author's  C-number  entry  in  the  C-number  field.  For  example 
“AB34(CD123)”  indicates  that  this  sheet  (“AB34”)  is  intended  to  be  a  replacement  for  the 
already-existing  “CD  123”. 

When  a  model  is  published,  the  C-number  may  be  replaced  by  a  standard  sequential  page 
number  (e.g.,  “pg.  17”). 

C.4.5. 2  The  “Number”  Field  (“Kit  Page  Number”  Small  Rectangle  Area) 

A  kit  page  number  is  written  by  the  librarian  at  the  right  hand  side  of  the  Number  field 
inside  the  small  rectangle.  This  is  composed  of  the  document  number  followed  by  the  letter 
identifying  the  sheet  within  the  document. 
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C.5  Keeping  Files 


Each  officially-assigned  participant  in  a  project  shall  maintain  Reader/ Author  files  of  the 
documents  received.  The  librarian  shall  maintain  the  official  Master  and  Reference  files  of 
the  project,  archiving  each  kit  submitted  during  the  course  of  the  project. 

Variations  in  the  filing  process  may  occur  based  on  individual  preferences,  but  the 
following  files,  maintained  in  alphabetically-sorted  reference  number  order  as  the  primary 
organizational  filing  structure,  are  the  minimum: 

•  Standard  Kit  Files 

Maintained  by  authors,  commenters  and  perhaps  other  readers.  File  Kit 
Cover  Sheets  chronologically,  as  a  master  log,  but  extract  and  file  most  C- 
pages  in  appropriate  Models,  in  node-reference  order.  When  in  doubt, 
leave  sheet  in  filed  Kit,  perhaps  adding  cross-referencing  Reader  Notes  on 
already-filed  diagram  forms  in  selected  other- filing  places,  as  well.  (Every 
sheet  is  the  property  of  the  Reader,  and  Reader-Note  numbering  restarts 
fresh  for  each  C-numbered  sheet,  so  the  added  personal  filing  Reader  Notes 
cannot  do  any  harm.) 

•  Updated  Current  Model  Files: 

Maintained  by  authors,  commenters  and  readers  from  Update  Kits  that  are 
received.  May  be  culled  in  favor  of  Project  Master  versions,  as  the  project 
progresses. 

•  Working  Files: 

Maintained  by  authors — and  any  Reader  who  initiates  any  ad  hoc 
interchange  between  participants  that  has  no  official  Author  assigned.  The 
Kit  Cover  Sheet  for  such  a  Reader-started  topic  should  be  suggestively 
named,  so  that  an  alphabetical  filing  of  Kit  contents  can  parallel  the  official 
Working  Files  of  models,  etc. 

•  Project  Files: 

Maintained  by  the  librarian  to  standards  set  by  the  project  management. 

C.6  The  IDEF  Model  Walk-Through  Procedure 

In  addition  to  the  Kit  Cycle,  a  Walk-Through  Procedure  has  been  developed  as  a  guide  for 
presenting  model  information  to  a  group  of  “reviewers”  (perhaps  only  weakly  experienced 
in  understanding  IDEFO  models  on  their  own).  It  does  not  substitute  for  the  Reader/Author 
Cycle  review  process  that  is  central  to  the  quality  assurance  of  IDEFO  modeling  (explained 
in  C.2),  but  may  be  streamlined  for  periodic  project  use  at  the  technical  level  to  provide  an 
opportunity  for  all  participants  to  share  or  develop  common  interpretations  that  may  not 
surface  in  the  one-on-one  Kit-based  interchanges. 

1 .  Present  the  model  to  be  analyzed  by  using  its  node  index.  This  is  the 
model's  table  of  contents.  Provides  a  quick  overview  of  what  is  to  come. 

2.  Present  selected  glossary  terms.  Encourage  each  reviewer  to  replace 
personal  meanings  of  words  with  those  that  the  presenting  team  has  chosen. 
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The  meanings  should  not  be  questioned  at  this  point.  A  change  in  meaning 
now  would  require  many  changes  in  the  diagrams. 

3 .  Present  each  diagram  for  review. 

The  diagram  walk-through  process  is  an  orderly,  step-by-step  process  where  questions  can 
be  asked  that  may  identify  potential  weaknesses  in  the  diagram  or  its  text.  Six  steps  of  a 
structured  walk-through  follow  below. 

Diagram  corrections  may  be  proposed  at  any  step.  These  corrections  may  be  noted  for 
execution  at  a  later  date  or  adopted  immediately. 

Step  1 :  Scan  the  diagram. 

This  step  allows  the  reader  to  obtain  general  impressions  about  the  content  of  the  diagram. 
Typically,  the  reader  will  have  reviewed  the  parent  diagram  which  depicted  the  current 
diagram  as  one  of  its  boxes.  The  reader  is  now  examining  how  the  author  decomposed  that 
function. 

Criteria  for  acceptance: 

1 .  The  decomposition  is  useful  for  its  purpose  and  is  complete  within  the 
context  of  its  parent  box.  All  lower  level  functions  can  clearly  be 
categorized  under  each  of  its  boxes. 

2.  The  diagram  reflects,  in  the  reviewer’s  opinion,  a  relevant  point  of  view 
based  on  the  purpose  of  the  model. 

3 .  In  the  opinion  of  the  reviewer,  there  is  enough  new  information  provided  to 
extend  understanding  of  the  parent  box.  There  is  not  so  much  detail  that  the 
diagram  appears  complex  and  hard  to  read. 

Unless  a  problem  is  rather  obvious,  criticism  may  be  delayed  until  Step  3  below.  However, 
first  impressions  should  not  be  lost.  They  might  be  put  on  a  blackboard  or  flip  chart  pad 
until  resolved. 

Step  2:  Look  at  the  parent. 

Once  the  reader  understands  the  current  diagram’s  decomposition,  the  parent  diagram 
should  be  reviewed  to  insure  compatibility. 

Criteria  for  acceptance: 

1 .  The  decomposition  covers  all  of  the  points  the  reviewer  anticipated  when 
reading  the  parent  diagram. 

2.  Now  that  the  decomposition  of  this  portion  of  the  parent  diagram  is 
revealed,  the  detail  which  the  reviewer  envisioned  for  this  box  should  still 
seem  correct.  If  not,  note  the  missing  detail. 

It  might  be  important  at  this  step  to  return  to  the  parent  diagram  briefly  and  add  new 
©-notes  (reader  notes)  or  embellish  existing  ones,  based  upon  the  added  insight  gained 
from  this  look  at  the  decomposition. 
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Step  3:  Connect  the  parent  box  and  the  detail  diagram. 


This  step  tests  the  arrow  interface  connections  from  the  parent  to  child. 

Criteria  for  acceptance: 

1 .  There  are  no  missing  or  extra  interface  arrows. 

2 .  Boundary  arrows  are  labeled  with  proper  ICOM  codes. 

3.  Child  arrow  labels  are  the  same  or  an  elaboration  of  its  parent’s  matching 
arrow.  Labels  convey  the  correct  and  complete  arrow  contents. 

4.  Examination  of  the  connecting  arrows  reveal  no  problems  in  the  parent 
diagram.  (An  added  interface  may  create  a  misunderstanding  of  the 
message  conveyed  by  the  parent.) 

A  clockwise  tour  of  the  four  edges  of  the  parent  box,  checking  each  arrow,  will  provide  a 
methodical  way  to  check  matching  of  ICOM  codes  boundary  arrows  to  the  parent  arrows. 

Step  4:  Examine  internal  arrow  pattern. 

The  pattern  of  boxes  and  arrows  constitutes  the  primary  expression  of  the  model  being 
created. 

Each  box  will  be  examined  in  node  number  order,  and  each  arrow  followed  in  ICOM  order 
for  each  box.  When  this  process  is  complete,  the  reviewers  should  be  led  through  the 
diagram  to  explore  the  consequences  of  situations  with  which  reviewers  are  familiar  and  to 
test  the  diagram’s  capability  to  simulate  the  relationships  known  to  exist. 

Criteria  for  acceptance: 

1 .  The  diagram  does  not  look  cluttered.  The  number  of  arrow  crossings  and 
bends  is  minimized. 

2.  The  boxes  should  be  balanced  with  regard  to  detail.  There  should  be  an 
equal  amount  of  detail  within  each  box.  However,  compromises  on  this 
criterion  are  acceptable  for  the  sake  of  clarity. 

3.  The  diagram  should  be  consistent  with  the  reviewer’s  experience  and 
knowledge  of  the  subject  matter.  Feedback  and  error  conditions  should  be 
shown  as  the  reviewer  expects. 

4.  The  level  of  detail  of  the  arrows  should  match  the  level  of  detail  of  the 
boxes.  Bundling  of  arrows  into  more  general  arrows  should  be  considered. 

Step  5:  Read  the  supportive  documentation. 

This  step  examines  the  points  that  the  author  highlights  in  the  text,  glossary  and 

FEOs. 

Criteria  for  acceptance: 

1 .  The  text  confirms  the  interpretation  obtained  from  examining  the  diagram 
itself. 
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2.  Normal-paths,  feedback,  error-handling  and  other  features  suggested  by  the 
text  are  found  in  the  diagram  or  found  in  a  FEO  (For  Exposition  Only) 
diagram. 

3.  Significant  diagram  features  uncovered  during  Steps  1-4  are  found  in  the 
text,  glossary  or  FEO. 

4.  References  to  the  diagram  are  detailed  enough  to  connect  text,  glossary  or 
FEO  to  specific  parts  of  a  diagram. 

Step  6:  Set  the  status  of  the  diagram. 

Set  the  status  of  the  diagram  (as  defined  earlier)  to: 

Working 

Draft 

Recommended 

Publication 


♦ 
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ANNEX  D  -  Informative  Definitions 


This  section  contains  definitions  which  relate  to  the  informative  annexes  of  this 
document.  See  Section  2  for  definitions  for  the  normative  sections.  A  term,  if 
defined,  is  defined  either  in  Section  2  or  Annex  D,  but  not  in  both. 

D.l  Approval  Level:  One  of  the  following  four  words  assigned  to  an  IDEF  model  to 
indicate  its  relative  degree  of  review  and  approval: 


(Lowest  level) 

(Next  to  lowest  level) 
(Next  to  highest  level) 
(Highest  level) 


Working 

Draft 

Recommended 

Publication 


D.2  Author:  The  person  who  prepares  and  is  responsible  for  any  specific  IDEF  model 
or  diagram. 

D.3  Clustering:  Boxes  are  split  and  clustered  in  diagramming.  Clustering  is  the 
grouping  of  two  or  more  boxes  to  form  a  single  box.  Its  goal  is  to  combine  multiple 
functions  into  a  single  more  general  function. 

D.4  Commenter:  A  reader  with  sufficient  training  in  an  IDEF  technique  to  offer  specific 
comments  using  the  reader  note  numbering  system  and  (often)  referring  to  flaws  in  the 
application  of  the  technique  itself. 

An  assigned  reader  who  shares  responsibility  with  the  author  for  the  quality  of  an  IDEF 
kit,  model,  diagram  or  other  IDEF  result. 

D.5  Draft:  See  approval  level. 

D.6  Expert:  A  person  familiar  with  a  part  of  the  real  world  system  (or  subject)  being 
modeled.  May  serve  as  a  source  of  information  or  as  a  reviewer  of  part  of  the  model. 

D.7  IDEF  Role:  A  position  in  an  IDEF  project.  See  author,  expert,  commenter,  reader 
and  librarian. 

D.8  Kit:  A  standardized  package  of  diagrams  containing  portions  of  or  complete-to-date 
models  to  be  reviewed.  See  Kit  Cycle. 

D.9  Kit  Cover  Sheet:  A  special  form  used  to  control  the  routing  of  a  kit  through  a  kit 
cycle. 

D.10  Kit  Cycle:  A  formal  Reader/ Author  Cycle  procedure  which  uses  kits  for  obtaining 
peer  or  expert  review  during  model  development. 

D.ll  Librarian:  The  person  responsible  for  routing  and  tracking  of  kits  and  keeping 
orderly  project  files  and  archives. 

D.12  Project  Field:  The  field  on  the  IDEF  diagram  form  which  records  the  name  of  the 
organized  task  for  which  an  IDEF  model  is  prepared. 

D.13  Publication:  See  approval  level. 
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D.14  Reader:  A  person  with  (limited)  training  in  an  IDEF  technique,  sufficient  to 
accurately  interpret  syntax  and  basic  meanings  and  to  read  and  write  reader  notes,  who 
sees  part  or  all  of  a  model. 

D.15  Reader/Author  Cycle:  A  procedure  using  reader  notes  for  obtaining  peer  or 
expert  review  during  model  development. 

D.16  Reader  Note:  A  textual  comment  by  a  reader  about  an  IDEFO  diagram.  Reader 
notes  are  not  published  as  part  of  the  diagram,  but  rather  are  used  for  communication 
during  a  Reader/Author  Cycle. 

D.17  Recommended:  See  approval  level. 

D.18  Reviewer:  A  reviewer  shares  accountability  for  the  utility  of  an  IDEF  kit,  model, 
diagram  or  other  IDEF  result.  Some  reviewers  lack  Readership  training,  but  participate  in 
guided  walk-throughs. 

D.19  Split:  Boxes  are  split  and  clustered  in  diagramming.  When  a  parent  box  is  detailed 
on  a  child  diagram,  the  parent  box  is  split  into  pieces,  some  of  which  may  then  be 
clustered,  to  form  the  3  to  6  boxes  on  the  child  diagram. 

D.20  Role:  Same  as  IDEF  Role. 

D.21  Working:  See  approval  level. 
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